I have a database that holds a time as UTC. This time can be shown in a webpage, so I’ve been asked to show it as local time in the page as it can be viewed from any country. A colleague mentioned something about getting the country settings from the current thread (on the server) but I couldn’t find any details on this. Is what I want to do possible?
If you (and your website) are comfortable with javascript, there is a very easy way to accomplish this.
First, on the server side, you would have the UTC date/time formatted in RFC 3339 format (the standard for internet time used by, among other protocols, icalendar). The basic syntax of RFC 3339 is:
YYYY-MM-DDTHH:MM:SS
Such that where I am, the time would be:
2010-05-04T05:52:33
But when the time is not local, but UTC, you add a Z to the end to denote this. So in my case, since I'm at -0500 hours from GMT, the same time above would be:
2010-05-04T10:52:33Z
So, first you get the server to output the above to your web page's javascript. The javascript can then parse that timestamp and it will output the date and time adjusted to the browser's time zone (which is determined by the computer hosting the browser). You should remember that if a user is from Tokyo and is viewing your website in Spain, they will see the timestamp in Tokyo time unless they've adjusted their computer's clock.
So the javascript would be:
var time_string_utc = some_server_variable; // timestamp from server
var time_string_utc_epoch = Date.parse(time_string_utc);
var time_utc = new Date();
time_utc.setTime(time_string_utc_epoch);
At this point, you have a javascript date object set to your UTC timestamp. A quick explanation of what happens above:
The first variable assumes you have passed the timestamp string to that variable from the server.
The second variable uses the Date.parse() method to convert the string to an epoch timestamp.
The third variable creates the unset Date object.
The last line line uses setTime method, which sets a Date object from an epoch timestamp.
Now that you have the object, you can output it to the user as you see fit. As a simple experiment, you can use:
document.write(time_utc);
which, if you are in my timezone using the UTC timestamp I started off with:
2010-05-04T10:52:33Z
would give:
Tue May 04 2010 05:52:33 GMT-0500 (CST)
but you can use various javascript methods to format the time into something much more pleasant looking.
No need to guess the user's country or even adjust your timestamp, so long as you trust the user's local browser/computer time zone.
Again, the short version:
var time_string_utc = some_server_variable; // UTC time from server
var time_string_utc_epoch = Date.parse(some_server_variable);
var time_utc = new Date();
time_utc.setTime(time_string_utc_epoch);
document.write(time_utc);
Also consider reading this thread which dives deeper in the dos and donts of handling daylight saving problem across timezones
Of-course is possible. You just need to find that country settings to detect the country your user comes from, and then modify the displayed date to fit that country's time.You can also find another way to detect the user country.(maybe from his ip address).
I am sure that the best way to manage this is let your colleague know that you need more details about the country settings implementation on your project and how can you use it.
EDIT:
Thinking about it I don't think it is possible to display the local time once you have the client’s culture. I'd certainly be interested to see your colleagues suggestion.
Getting the US culture, for example, won't help as the US has many timezones.
I think using Javascript like Anthony suggests would be the way to go...
OLD:
You can override the InitializeCulture() method with code that sets the current (chosen or browser reporting) cultures:
Thread.CurrentThread.CurrentCulture =
CultureInfo.CreateSpecificCulture(selectedLanguage);
Thread.CurrentThread.CurrentUICulture = new
CultureInfo(selectedLanguage);
this is how I've done it in PHP in the login file which connects to MySQL database:
//set local timezone
date_default_timezone_set('America/Denver'); //use local TZ
Then, every time you access the DB, you are setting the timezone for that session and any input/output associated with it.
Related
I have a simple class that contains a DateTime property. When I set the value of this property using DateTime.Now() the value is correct. However, when I pass this class object as a parameter via SignalR, on the receiving end SignalR has changed the DateTime so that it no longer matches the original DateTime. How can I get SignalR to stop manipulating my DateTime values? This issue seems to have started with a recent update to the latest SignalR nuget packages.
This seems to be a problem when the hub and the client are in two different time zones. It seems Microsoft is trying to help, by adjusting the date/time to the local time zone, but I want the original value, not the value Microsoft "thinks" I want.
When you want two systems to communicate with each other I would recommend using always the DateTime in UTC for various reasons. In your case you have two options here:
1 - Send the date as string string date = DateTime.Now.ToString(CultureInfo.InvariantCulture); so on the client side you just need to parse the datetime like DateTime.Parse(date, CultureInfo.InvariantCulture);.
2 - Send the date in UTC like DateTime.UtcNow; so event if the SignalR tries to change the date, it will have the DateTime.Kind as UTC. In this case or you will get the current date correctly, or you just adjust on the client side to the local time like receivedDate.ToLocalTime();
This one was a real head scratcher as I had the exact same issue. The client was storing the correct time but by the time it hit the Hub... it had changed. I'm really glad you posted this as I wouldn't have imagined this issue being possible. #Kiril1512 posted the correct resolution. In my case I used his second option as I didn't want to change my model... although simply converting to a string would have been simpler. While I did follow his suggestion and convert everything to DateTime.UtcNow()... I am thinking this was unnecessary as I noticed even previously stored dates converted correctly. This makes me think that either this isn't necessary to do, or dates are converted to Utc when they hit the Hub automatically which may be what the issue was to begin with?
Either way I posted this as I discovered that converting this date back to Local time was a little more involved. Here is how I ended up doing the conversion which resolved this issue for me that I gathered from this resource:
DateTime convertedDate = DateTime.SpecifyKind(
DateTime.Parse(msg.CreatedOn.ToString()),
DateTimeKind.Utc);
var kind = convertedDate.Kind;
DateTime dt = convertedDate.ToLocalTime();
We and foolishly assumed a block of momentjs code would work in all browsers. Right now its correctly working in chrome, but all other browsers its not applying the UTC offset. How do I make this code work consistently in other browsers? Right now chrome is working, all others are not.
new moment(new Date(date)).fromNow();
//below shows an example of an exact date.
var now = new moment(new Date("2013-09-30T23:33:36.937")).fromNow();
In chrome you would see something like "now", all other browsers you would see "in 4 hours"
The way to get it to work:
var now = moment.utc("2013-10-01T13:15:30.937").fromNow();
Note that if you turn it into a "Date" and call moment.utc
var now = moment.utc(new Date("2013-10-01T13:15:30.937")).fromNow();
It will not work. It makes sense now that I think of it.
Original Answer
Try this:
var now = moment(date).fromNow();
But rutter is correct that you should specify either a Z or an offset like -07:00. From .net, you should make sure you use either a DateTime with .Kind set to Utc, or use a DateTimeOffset field.
Expanded Answer
You should understand that when you send a string of 2013-10-01T13:15:30.937, you are not sending any context with it. There is no way to know from that string alone whether the time is at UTC, or in your server's time zone, or in the browser's time zone.
If you pass it directly to moment("2013-10-01T13:15:30.937"), it is going to assume the context of the browser's local time zone.
As you discovered, you can tell moment explicitly that this time is in UTC by using the .utc function, such as moment.utc("2013-10-01T13:15:30.937").
While this will work, there are good reasons not to rely on that alone. For example, what if you ever use the same server API for another application, or perhaps for third-parties to consume? Unless you tell them separately that the timestamp is meant to represent UTC, then there is no way to know that.
These strings are in the ISO 8601 / RFC 3339 format. Part of that specification describes how to indicate that a timestamp is in UTC. You simply add a Z at the end. If you supply the Z then any consumer of this timestamp will know that the time should be interpreted as UTC. And sure enough, if you pass that into moment directly, such as moment("2013-10-01T13:15:30.937Z"), it will give the result you expected.
You said in comments that you were generating these values from ASP.Net Web API. Run your application in debug mode and set a breakpoint so you can examine the output of your controller. When you look at the specific DateTime property in question, you will see that it has its own .Kind property. It is probably set to DateTimeKind.Unspecified.
Since you said specifically that your application uses UTC, then these values should have DateTimeKind.Utc instead. Once that is set, then WebAPI will properly emit the Z at the end of the timestamp.
Somewhere in your server-side code, you should do something like this:
dt = DateTime.SpecifyKind(dt, DateTimeKind.Utc);
You should do this as early as possible. For example, in your data access layer when you retrieve the value from the database. If that's not possible, then at least you should do it in your API Controller so the value gets emitted properly.
See also the MSDN reference for DateTimeKind and DateTime.SpecifyKind.
Also - the reason you were getting browser inconsistencies is because you were using the Date object's constructor instead of the parsing functions built in to moment. While moment will accept a Date, there are several known problems and inconsistencies with how browsers support parsing a Date from a string. Some of those inconsistencies are documented here.
Use this:
var lastLoginTime = moment(user.lastLoginTime).fromNow();
I register the following javascript on my web page. When the user posts back, SOMETIMES the txtTimeZoneOffSet hidden field comes back as blank. When I test on my computer, I always get a value. It happens on different browsers (I.E, FireFox, and Safari).
I am trying to get the users offset, so when they enter a date, I can convert it to UTC on the server and deal with everything in the same timezone, then when I render dates back out to them, I make sure it is in their timezone.
<script type='text/javascript'>
$(window).load(function () {
var d = new Date();
var tz = d.getTimezoneOffset();
$('#txtTimeZoneOffSet').val(tz / 60);
});
</script>
Does anyone see why this would not work 100% of the time?
The jQuery looks fine to me, so I don't see why it wouldn't work unless JavaScript was disabled or you didn't load jQuery.
However, you are worked on a flawed assumption that the user's current offset will be the same for all dates. In any time zone that has daylight saving time, it could be wrong.
The better approach would be to convert to UTC on the browser. Or at least use the date/time in question in the call to getTimezoneOffset.
UPDATED ANSWER
In response to your question, the code you have now will get the current offset already. You are just not guaranteed that it will be the same offset for any date they might enter. For example:
<input type="text" id="someDate" />
var someDateString = $('#someDate').val();
var dt = new Date(someDateString);
var offset = dt.getTimezoneOffset();
Since the value of the text input is variable, in many time zones you will get a different offset for January than you will for June. So the better thing would be to just convert it to UTC on the browser:
var someDateString = $('#someDate').val();
var dt = new Date(someDateString);
var s = dt.toISOString();
The string s will be in ISO8601 format, and will already be converted to UTC.
Of course, if it were me I would do this using moment.js - since it gives you much better control of how the input string is parsed.
This approach is usually good enough. HOWEVER, if there is any chance you will have to do this conversion on the server, perhaps because the user is not present, then you must know their time zone. Not just the offset, but the actual time zone. See "Time Zone != Offset" in the timezone tag wiki.
The best way is to ask them for it. A map-based picker like this one is a nice touch. You can even guess at a default selection using jsTimezoneDetect. Ultimately you are after a string identifier like America/New_York that you can use on your server. In .Net you can use these with the TZDB provider in Noda Time.
If you don't want any fancy libraries, you can stick with Windows time zones, and present a dropdown list from TimeZoneInfo.GetSystemTimeZones(), where the .Id is the key and the .DisplayName is the value.
I have a site that saves a date in my model to the database.
After launching my site I realised that the server has US regional settings so I had to make sure that all date's on the public site were formatted in the UK format.
However now when I go to my 'Create' page and choose a date and click save I get the error The value '22/11/2009' is not valid for the Date field. which must be coming from the default DataAnnotations on my model.
Is there something I can do to get it to accept UK formatted dates?
I managed to get it working by putting this into the web.config
<globalization culture="en-GB"/>
Have you tried this? If this site is only used in the UK, you can probably put this in the Global.asax Application_Init. If it is based on the user, you can put it in Application_BeginRequest. This will provide the default formatting and parsing for all dates and numbers in the application.
Thread.CurrentThread.CurrentCulture = CultureInfo.GetCultureInfo("en-gb");
Thread.CurrentThread.CurrentUICulture = CultureInfo.GetCultureInfo("en-gb");
Do what SO does: persist all dates in UTC and render them as UCT with an appended "Z" for GMT/UTC/Zulu. It might not be ideal but sometimes the gain from simplicity outweighs the costs of the alternative. Think about that.
Is it possible to display local times to users without using Javascript when you store the values as UTC?
You would need serverside to be aware of the clients timezone. There isn't enough information in the typical request to make that determination, the closest you can get is the Accept_Language header which might give you a clue but is hardly useful enough (esp. if the client is in a country that has multiple timezones).
Hence you would need to user to tell you what their timezone is and then use a logon or cookie to store that info.
You could do the conversion on the serverside in vb.net, c# or whatever .net language your using. You are going to have to convert to the local time somewhere.
Your asking a very broad question with no detail so I can't recommend how to do this on the server.
Edit
Based on the comments I see the problem your having is that you want to figure out what the users timezone is without javascript. I always have the user tell me their timezone when they register.
One approach which won't be perfect would be would to be use a geo-ip lookup service that will tell you most likely where your user and give your better granularity then using the language settings.
Think this is the closest you can do:
using System.Globalization;
// get the first language from request (en, fr, ru)
var primaryLanguage = Request.UserLanguages.First().Split(";").First();
// find a culture by this language
var culture = new CultureInfo(primaryLanguage);
// if the culture is neutral, try to find the specific one
if (culture.IsNeutralCulture)
culture = CultureInfo.GetCultures(CultureTypes.SpecificCultures).FirstOrDefault(o => o.TwoLetterISOLanguageName == primaryLanguage);
// get the string from a datetime
var datetimeText = culture ? DateTime.Now.ToString(culture) : DateTime.Now.ToString();