My client is in india and server in USA . If user submit his post from india it get stored in USA server so when i display post submit time to user it is as per USA time . I want to show it as per clients timezone
The simplest way to handle timezones is to work with Epoch time behind the scenes, and translate it to the user's preferred timezone on render (or with client-side code).
Epoch time is the number of seconds since it became 1 January 1970 in London. For example, right now the time is 1483130714. This means we've got one simple number, that can be effortlessly compared and sorted, to represent precise moments without needing to care about dates, timezones, locales and their frustrating details. Virtually all languages in popular use have the ability to parse these numbers into their own timestamp values. In JavaScript, you can do this with new Date(1483130714). You'll get a date object and you can then present that however you like (eg with toLocaleString).
If you don't use Epoch time, you'd want to use UTC, the next-best thing. The important thing is to store in a consistent universally-understood format and then translate it to the user's preferred form as needed.
You need to store date in UTC and then convert it as per browser culture and timezone. So store all dates in UTC and depending on browser culture you can add offset, this could be tricky if user sets wrong culture and time.
Related
I have a .NET web site that captures a C# DateTime value and stores it in database with UTC value. Upon showing that datetime value on web page, what I want is that date time UTC value to be converted to web user's local time zone properly. So web users in different time zones will see the displayed date time value with different date time results.
I have 2 following approaches. I do not know which is the best and correct one.
Approach 1: Let C# server side codes to convert the UTC DateTime value to local date time using .NET library method DateTime.ToLocalTime() and pass that converted value to client side to display without any further client side codes.
Approach 2: I do not do any time conversion using C# server side codes. Instead, I simply pass the UTC datetime value to client side and I will use some client side (javaScript or some JS library) codes to do the conversion before displaying it to web user.
Question 1: Approach 1 or Approach 2 is the best and correct one?
Question 2: The .NET library DateTime.ToLocalTime() method will convert a datetime value to local time of web user; web server's local time; OR web user's computer OS time?
Question 3: How can I test my web page with different time zones to see the best/correct approach working?
Thank you for your help.
I suggest that all date/times be stored in UTC on the server and that, in your case, you do the web client timezone conversion on the client side. I suggest the Moment library for client-side operations. If you use Moment, look at the guess() method for determining the client's current timezone.
By the way, you might want to determine the client's current timezone periodically in case 1) the user in on a mobile device and physically moves to another timezone or, 2) the user's session lasts long enough to transition from Daylight Savings Time (DST) to Standard Time (STD) or vice versa.
Now, I said "in you case" because, based on your question you don't seem to need to worry about calculating time intervals between 2 date/times. If you need to do that you also have to consider the complication of changes in a timezone from 3 sources:
Changing from STD to DST (and vice versa) that occurs twice a year in many timezones.
Changes to the UTC offset of a timezone that sometimes happens when a government implements a change.
Changes to the date/time when a location converts from STD to DST or vice versa.
Also, you might need to consider the complication of dealing with the potential for a local time corresponding to two UTC times! This can happen when a local time for a location falls within the 1 hour preceeding the date/time when that location converts from DST to STD. That 1 hour period is repeated when a 'fallback' from DST to STD time occurs and so you need to resolve which of 2 possible UTC times you want to store in your database.
If any of the above timezone complications might exist for you, consider storing a location along with the date/time since this context is required for timezone calculations. The location can be lat/lon which you would need to map to a timezone or you could keep it simple and store just the timezone. Lat/lon is sometimes more desirable since sometimes governments decide to move a location into a new timezone (but this is pretty rare).
See the title: for the solution I'm working on, I need to get the current timezone offset (from the client, running javascript/jQuery) and use it in backend C# code.
The question is rather similar to the one asked here, but there are a few differences - the main one being that I am pretty sure that the time on the client computer won't be tampered with. So new Date().getTimezoneOffset() will do just fine.
I cannot read the value upon submitting a form since the user is not working in a form: after the user has logged in, among the items that are visible on the screen is a table with data entered by the user or by other users. This data contains UTC datetimes that have to be adjusted according to the client's timezone. C# code is responsible for retrieving and formatting the data - hence my question.
What would suffice, is storing the value somewhere so that C# can read it when necessary. But I don't think that can be done as well. What would be the approach here?
Thanks in advance!
Your suggested approach is flawed in that the current offset from the client's browser is only going to apply to the current date and time. In reality, time zone offsets change over time within a given time zone. You cannot just take a singular offset from one point in time and expect to use it to convert other dates and times to the same time zone. Instead, you need to use the string that identifies the time zone, not an offset from that zone.
As an example, consider the Eastern time zone in the United States. For part of the year, it uses UTC-5, and we call it Eastern Standard Time (EST). In another other part of the year, it uses UTC-4, and we call it Eastern Daylight Time (EDT). This time zone is identified by either the IANA time zone ID "America/New_York", or the Windows time zone ID "Eastern Standard Time" (which covers the entire zone, both EST and EDT despite its wording).
So, break this problem apart into a few steps:
In JavaScript, identify the users's IANA time zone (America/New_York):
If you are targeting modern web browsers, you can call this function:
Intl.DateTimeFormat().resolvedOptions().timeZone
If you need to support older web browsers, you can use jsTimeZoneDetect, or moment.tz.guess() from Moment-Timezone.
Send that string to your web server through whatever mechinsm you like (form post, XHR, fetch, etc.)
In your .NET code, receive that string and use it to reference the time zone and do the conversion. You have two options:
You can use Noda Time, passing the IANA time zone ID to DateTimeZoneProviders.Tzdb as shown in the example on the home page.
You can use .NET's built-in TimeZoneInfo object. If you're running .NET Core on non-Windows systems (Linux, OSX, etc.) you can just pass the IANA time zone ID to TimeZoneInfo.FindSystemTimeZoneById. If you are on Windows, you'll need to first convert it to a Windows time zone ID ("Eastern Standard Time"). You can use TZConvert.GetTimeZoneInfo from my TimeZoneConverter library.
Once you have either a DateTimeZone from Noda Time, or a TimeZoneInfo object, you can use the methods on it to convert UTC values to local time values for that time zone. Each of these will apply the correct offset for the point in time being converted.
I'll also say, many applications simply ask the user to choose their time zone from a dropdown list and save it in a user profile. As long as you're storing a time zone identifier string and not just a numeric offset, this approach is perfectly acceptable to replace steps 1 and 2 above.
In our application we are Saving the UTC DateTime in DataBase. Client (javascript) is sending the datetime in Local TimeZone and at controller level we are converting it to UTC time before saving the date in Database.
Both the client and servers are on different timezones.
we are fetching date from database in UTC Using Entity Framework with
DateTime.SpecifyKind(_CreatedDate, DateTimeKind.Utc);
So should we again convert the DateTime to local DateTime at controller or should we handle all the DateTime conversion logic at the client.
When sending DateTime instances to the server conversion conversion to UTC should happen as early as possible. In this case by the client and as your client is javascript you can use the method toUTCString. If you are using momentjs you can use utc.
When receiving DateTime instances from the server conversion conversion to local time should happen as late as possible. Make sure that persisted dates/retrieved dates are in UTC when you create them. Again, it is the client that should be converting them to local date time instance.
Finally send all datetime instances between client and server using ISO8601 format. Momentjs, javascript's date object, json.net all can do this. This ensures nothing is lost and no cultural specific bugs are introduced.
As to why it should be handled at the client is very simple, its easiest to do it there. Only the client truly knows its timezone, this is usually very difficult to "guess accurately" on the server side. The only reason not to do this is if you wanted to store a users timezone info with their profile but even this can get very tricky (what happens if the user travels or if they move location, etc).
As to how to persist you can use either a DateTime type or a DateTime with offset type (the true type names depend on the RDBMs you are using). Which one you choose should depend on if it is important to know the offset from utc at the moment it was saved. So far I have not had a need to do this but maybe it is important for you. It has no influence on the actual point in time as a DateTime should represent the UTC point in time and with offset should represent the local time with offset to get back to the UTC point in time.
Here's the way we do it in our projects. In my opinion, you should be using datetimeoffset in your database. This allows you to be able to identify what timezone the date was saved in. Then, when you send your date from your client to your server, just make sure it's sent in datetimeoffset.
When you send the datetimeoffset from the server to the client, you can do the conversion on the client side. I don't think anybody would argue that MomentJS Timezone is the best library for this. Look over it and give it a shot.
http://momentjs.com/timezone/
Elaborating on DateTimeOffset
DateTimeOffset is another datatype like datetime except datetimeoffset adds an hour offset to determine the timezone. For instance, let's say you're in Central Timezone and you want to save the time 08:00 am. Well, in Datetimeoffset, it would be something like 08:00:00:00 -04:00 declaring that the offset was -4 (central timezone). This makes it easy because you don't have to do any math in your head when reading it and you really don't have to do any conversions (let MomentJS do it for you). When you read it, you will always know that "Oh, it was 08:00 am for whomever saved the time, and it looks like they saved it in Central timezone."
Since it's quite relative when is the "Proper" time to convert.
The only absolute rule i think is valid is this one.
UTC time is the only Real meaningful data
Any other conversion to any timezone is just a "Display" for me
So follow the same rules as you would with the rest of your data.
Like converting a Boolean to a Checkbox on the view.Or sending that checkbox value as Boolean to the server.
And that's the soonest it Reaches or Leaves the UI.
I am looking for a JavaScript based time picker (jquery, extjs, bootstrap etc) control which converts the local time into UTC time. It must take into consideration user location and provide accurate time.
There are lot of controls available which allows you to pick time but I want to know what is the most accurate way to convert the time into UTC equivalent. There are lots of post available which talks about converting time into UTC but some of the post are old and some of them have one or the other catch.
What I am trying to do:
Assume the local time on user machine is 10 AM. I am asking user to pick a time > current time (or a future time). Assume user picks 11:30 AM. I want convert the 11:30 AM (local to his timezone) into UTC equivalent.
I am looking for recommendations on displaying times in a web application in a time zone other than the user's current time zone.
We store our dates/times in UTC/GMT in the database, so it is not an issue to format the time for UTC/GMT or the user's current time zone. However, in other situations we need to display the time from the point of view of an arbitrary time zone (i.e. every date/time on this page is in Eastern, regardless of whether or not the user is in West Coast, Central, Eastern, etc.).
In the past we have stored offsets or time zone info, then done the calculations in server code in .Net or else we have done some client-side manipulations in javascript that I would prefer to avoid, since it all becomes very dependent on javascript and the user's browser. I'd like to know the best way to do this in a more client-side/MVC type application.
Here is an example:
Date stored in db: 1302790667 (Thu, 14 Apr 2011 14:17:47 GMT)
Converted date displayed for a client in Central time zone: Thu Apr 14 09:17:47 2011
Date I actually want to display, always in Eastern time zone: Thu Apr 14 10:17:47 2011
In the above example, it's easy to get the time in UTC (#1) or the user's current time zone (#2) but it is more difficult to get #3. My options seem to be:
Store offsets or time zones in the db and do calculations on the client - this is what we've done in the past with .Net but it seems even messier in client side code is the path we are currently trying to avoid.
Do the conversion on the server and send down a full date for display to the client - client receives a string ("Thu Apr 14 10:17:47 2011"). This works but it's not very flexible.
Do the conversion on the server, break it into parts and send those down to the client, then put them back together. ("{DayOfWeek:Thu, Month:Apr, Day:14, Hour:10, Minute:17}"). This gives us the correct data and gives us more flexibility in formatting the date but it feels a little wrong for this scenario.
Any other options ideas? How do others handle similar situations? Thanks.
Our results:
I tried out a few libraries like Datejs, MS Ajax, etc. and I was never very happy with them. Datejs didn't work at all in a few of my test cases, is not actively maintained, and seemed to focus a lot on syntactic sugar that we don't need (date.today().first().thursday(), etc.)
We do use jQuery for some basic date/time parsing.
I came across a lot of "roll-your-own" client-side date conversion "hacks", most of which only addressed the conversion to UTC, started off working fine, and then eventually fell apart on some edge case. This one was the 90% solution for a lot of standard UTC conversion but didn't solve our "arbitrary timezone" issue.
Between the code complexity the conversion routines added and the bugs they seemed to cause, we decided to avoid client side date processing most of the time. We do the date conversions on the server with our existing date handling routines and pass the formatted dates or info down as properties to be used by the view. If we need a separate date, we just add another property. There are usually only a few properties that we need at a time (i.e. EventDateUTC, EventDateLocal, EventDateAlwaysAustralia, and EventDayOfWeek).
I offer the suggestion that you look into the Datejs library. It offers a bunch of extensions to basic JavaScript date manipulation, including a "setTimezone()" method and flexible ways to convert a date into a formatted string for display.
I usually hesitate to suggest libraries when their use is not explicitly allowed for in questions, but Datejs isn't very large and it's pretty solid (even though it's called an "alpha" release). If you'd prefer not to rely on something like that, you might want to look at it anyway just to see the basics of how its extensions were implemented.