in my app the user selects a date + time, and a timezone. This choice must be shown to other users IN THEIR OWN timezone, which means if user A from New York chooses August 8, 3:00 AM in EDT, user B from Beijing will see this datetime converted to China Standard Time (CST).
To do this I thought - ok I save user A's date and tell him to select out of 4 timezones. Server side I convert this from his EDT choice to UTC using moment timezone, and save it as UTC in the database, so that when I read it, I convert it back to other users according to their own timezones.
Is this a correct approach or am I overcomplicating things? THe purpose is that user A can choose her desired timezone, database saves as normalized UTC, target user sees in his own timezone.
(im using node.js for serverside btw)
Thanks,
Your approach is correct : save the time in UTC in the database and display it to the users according to their timezones.
momentjs can help you to do it but you need to give it the file of historical timezone changes.
check http://momentjs.com/timezone/ for further explanations.
once you have this, it is as easy as
var jun = moment("2014-06-01T12:00:00Z");
jun.tz('America/Los_Angeles').format('ha z'); // 5am PDT
also: don't store the user timezone as EDT, CST or -6. The hour shift can change with Summer times, Winter times, .. you need to store the Olson format, 'America/Los_Angeles'
Related
The context
I've got an application that lets an admin configure a timezone for their company. Other users, then, can modify the schedule of the company, but it should be always saved with the company's timezone.
This data needs to be stored in UTC in the server, and whenever someone gets it back it needs to be displayed with the company's timezone time.
For example:
Admin sets timezone to "Europe/Madrid" (GMT +01:00).
User A, in timezone "America/Sao Paulo" (GMT -03:00), sets the Schedule to 09:00 - 15:00 (two dates).
The schedule needs to be sent to service in UTC as if the user was in 'Europe/Madrid'.
Service stores the date in UTC
After that, someone in timezone "Europe/Athens" (GMT +02:00) visits the page and they have to see the time as if they were in "Europe/Madrid". So, in this case, 09:00 selected in "America/Sao Paulo" should be stored as "08:00 UTC" (Madrid timezone).
What I need
Basically, I need the time, no matter what is the timezone, to be displayed as if the user was always in the company's timezone, and whenever someone saves the schedule time, I need it to be saved as if they also were in "Europe/Madrid".
Also, the displayed time shouldn't change in DST, as the schedule will be always the same for all the year. So, the user should see all year the "09:00 - 15:00" schedule.
Keep in mind that the server uses SSR, and this means that in the first render we do not know the local timezone of the user who's going to see the data.
What I've tried
I've tried libraries such as "date-fns-tz" and "moment-tz" to convert the dates, but they do not work for the intended, as whenever I parse it to UTC they do it ok but when I try to parse it again to the desired timezone they do not work as expected.
I've tried "countries-and-timezones" library to get the timezone offset and try to manually adjust the dates, but I keep getting messed up by the server's local timezone (which I suspect is the reason why the other libraries didn't work as expected either).
Is there some way I can achieve that?
Thank you.
Basically you'll want to forget about the user's local timezone. America/Sao Paulo should play absolutely zero role in any of this. When the user enters "9:00" in the browser, you just want that to be "9:00" and nothing else. Since the company's timezone is Madrid, you want the input "9:00" to be interpreted as "9:00 Madrid". You can do that either client-side or server-side. But at no point do you want any conversion going on from Sao Paulo time to Madrid time.
Secondarily, you'll want to be very clear what you're storing in the database and what you'll do with this information later. To be clear, what does not work and what you need to avoid is this:
user enters "9:00"
you store 2022-12-01T08:00:00Z in the database
you automatically generate future dates like 2023-05-01T08:00:00Z from it
That generated date in May will be 10:00 Madrid, not 9:00.
You pretty much have two choices:
store just "9:00 Madrid" in the database, i.e. a description of a rule that you can later use to generate times
generate concrete timestamps in the Madrid timezone, convert them to UTC, then store them
Which one is more appropriate depends on how you intent to use them. If you want concrete timestamps in your database to query by, then you need to follow these steps:
get input "9:00 Madrid"
create a concrete date 2022-12-01T09:00:00+01:00
convert it to UTC 2022-12-01T08:00:00Z to store it
generate a future date by adding days/weeks/months to it, keeping the time value the same, e.g. 2023-05-01T09:00:00+02:00
convert it to UTC 2023-05-01T07:00:00Z to store it
for display, convert the UTC date to the company's timezone, and display it in that timezone; i.e. the user's local timezone plays absolutely no role (right?)
To do any time arithmetic, you basically want to construct new dates by combining parts of the existing date, in order to avoid changes to the time-of-day. The details will depend on the exact library being used, but in pseudocode it's something like:
var a = new Date(2022, 12, 1, 9, 0, 0, 'Europe/Madrid')
var b = Date.combine(a.date.add(6, 'months'), a.time, a.timezone)
// 2023-05-01 9:00:00 Europe/Madrid
Hope this helps to clarify things a bit.
I've tried searching for this but it's a pretty specific question. I have a React application where users will be looking at a calendar that can be switch between multiple timezones. I'm using Moment with it's Timezone plugin to try and standardize these times as much as possible.
There is a use case with this application where, for example, a user may be in the US/Eastern (UTC -05:00) timezone viewing a calendar that is set in the US/Mountain (UTC -07:00) timezone.
Right now, I'm keeping my dates in UTC to try and minimize the confusion, however I will need this user, in the Eastern timezone, to be able to see the date in the Mountain timezone. For instance, clicking on a calendar appointment, which is set in Mountain time, will display at 3pm MT. However, right now, when I take the UTC date, it's being converted into the user's local time. A 3pm MT appointment is displaying as 5pm ET.
// I'd like it to display 2017-12-20T15:00:00-07.00 to the end user
moment('2017-12-20T22:00:00Z').format() // returns 2017-12-20T17:00:00-05.00
My question is, using the calendar offset (UTC -07:00), how can I display that time in MT as opposed to the user's local time using Moment and Moment Timezone? I don't have access to any other timezone information, besides the offset. I'm tried going through Moment Timezone's docs but it seems I need a name to create the time in a timezone different from the user's local timezone.
To use moment-timezone, you will need moment#2.9.0+, moment-timezone.js, and the moment-timezone data.
I think this will helps you.
https://momentjs.com/timezone/docs/
I have MVC web application. I am storing UTC time in database. (Not datetime but just a time). In C# When I retrieve this time from the database I get timespan object back. I also have offset available in minutes. For example.
double offset = 600;
How do I use this offset to convert timespan to local datetime.
Note I don't want to use DateTime.ToLocalTime () method because that will use server's timezone.
UPDATE1
I am using the Javascript new Date().getTimezoneOffset() method to get the client's offset, and i have offset value stored on the server. Then I also have drop down list that show times as 12:00 AM, 12.30 AM, 1:00 AM etc etc. The dropdownlist is bound to model property SelectedDateTime of type DateTime. Idea is to convert user selected time to UTC and then UTC to localtime based on the offset. So lets say i have offset 300 minitues that would be 300/60 = 5 hours
double offset = 5.00; // this is available on the server
When the user selects time in a drop down list, I am getting a datetime object on the server, ignoring the date part i want to store UTC time into database. This is how I'm converting to UTC time.
TimeSpan utcTime = SelectedDateTime.AddHours(offset).TimeOfday;
I store this utcTime into the database. Now I want to convert UTC timespan into the client's datetime.
I am assuming i have Subtract offset now
var newLocalTimeSpan = utcTime.Subtract(TimeSpan.FromHours(offset));
var newLocalDateTime = new DateTime(newLocalTimeSpan.Ticks, DateTimeKind.Local);
However this throws the error:
Ticks must be between DateTime.MinValue.Ticks and
DateTime.MaxValue.Ticks.\r\nParameter name: ticks
For example with offest 5 hours, If user selects 8:00 PM then it will be converted to UTC and will be stored as 01:00:00.0000000 in database. When I retrieve the UTC value from database its '1:00:00 AM'. Then I subtract 5 hours form this TimeSpan which equals to `-4' now and if I pass Ticks to DateTime..i get above error.
NOTES: If you are curious why model property is DateTime instead of TimeSpan thats because i am using Kendo TimePicker which needs DateTime type.
UPDATE 2
I really appreciate all for your help. I have gone through all the articles #Matt Johnson has posted and it looks like I should not be using offset for calculating the UTC time. Mainly because of the day light time saving. But instead I should be using timezone. So I have 3 options here to find client’s time zone:
1> Use JavaScript to detect time zone
In JavaScript I can do new Date().toString() which returns date time as Sun May 22 2016 02:12:36 GMT-0500 (Central Daylight Time) I can then parse the string to get “Central Daylight Time” and post it to the server. However on server, for .net “Central Daylight Time” is not a valid windows time zone ID.
Question
Is this correct approach? Is JavaScript returning IANA zone id? Will it always return IANA zone id?
If JavaScript is returning IANA Id then I can use Matt’s article here to get windows time zone id
2> Use http://momentjs.com/ to detect client’s time zone
Question
Is momentjs returns IANA zone id?
If momentjs return IANA zone id then I can use Matt’s article above to get windows zone id. One of the reason I don’t like this approach is because I have to use 2 third party libraries momentjs and Noda Time
3> Provide user a drop down list using TimeZoneInfo.GetSystemTimeZones() and let the user selects the timezone.
User will select a time and timezone, then on server I will convert it to UTC using selected timezone and save it DB. However I have to show that time on some other pages, So I again need timezone. That means I have to put the drop down list in such a place on UI where it will be available all the time. Like top menu.
(I can certainly save timezone into DB along with the time, however if user travel to other place he will still see time in initially selected time zone. Which I don’t want)
Are these correct approaches? Am i missing something?
Question
Assume that I implement timezone selection using one of the approach above and i have correct client's time zone with windows timezone id on server in some variable.
Now lets say user selects 6:00 PM (Central Daylight Time , UTC -5) which will convert to UTC as 23:00:00. As long we are in Central Daylight Time the conversion from UTC to local will show 6:00 PM. Once we go into Central Standard Time which is UTC -6 Will the conversion still show 6:00 PM or 5:00 PM?
I am planning to use TimeZoneInfo.ConvertFromUtc(datetimevalue, timezone) method for converting UTC to Local
In general, there are only two viable approaches:
Pass only UTC dates and times to the client, and do all conversions to local time in the browser using JavaScript.
Use this approach when you don't care what the time zone actually is, but you just want it to match the browser's local time.
The Date object can do this, but you may find it easier to use a library such as moment.js, which gives you better control of output format, among other things.
Apply a time zone (not just an offset) to the UTC date and time on the server side, to produce the correct local time value.
Use this approach when the time zone affects an entire application, and needs to be known in server-side business logic.
You can try to guess the user's time zone using jsTimeZoneDetect or moment.tz.guess() in moment-timezone. However, it's just a guess, and it is always an IANA time zone ID (such as America/Los_Angeles).
Asking the user for their time zone from a list is a good idea. Usually one would place this on a user settings or profile page. You can use the guess made earlier to pick a default value from the list.
You will indeed need to use Noda Time on the server if you are using IANA time zones on the client.
Some applications choose to list Windows time zones instead, which is a much simpler approach as you can get everything from the TimeZoneInfo class. However, recognize that there are limitations with this approach including:
Localization issues, as you cannot easily get at display name strings other than the ones matching the operating system's default language, not .NET's globalization and localization features.
Maintainability issues, as you yield control to the operating system for keeping the time zone data updated. This may seem more convenient, but you may find that your hands are tied when keeping up with short-notice time zone changes. This is especially problematic when you don't have control over how or when updates are applied to the OS, such as with Microsoft Azure App Service.
Compatibility issues, as Windows time zones aren't generally recognized outside of Windows. If you ever expose the user's time zone setting in an API, you'll likely have translation issues for callers from other platforms.
Now, getting to your specific points:
I am using javascript new Date().getTimezoneOffset() method to get the client's offset...
That gives you the client's current offset. You have no guarantees that it is the correct time zone to apply for an arbitrary date and time.
If wanted to apply a fixed offset to a UTC DateTime in C#, the best way is with a DateTimeOffset.
DateTime utc = new DateTime(2016, 12, 31, 0, 0, 0, DateTimeKind.Utc);
DateTimeOffset dto = new DateTimeOffset(utc); // DateTimeKind matters here
TimeSpan offset = TimeSpan.FromMinutes(-300); // The offset is inverse of JavaScript's
DateTimeOffset result = dto.ToOffset(offset);
But do note this is only for a fixed time zone offset. For a true time zone, you would use the TimeZoneInfo class if you're using Windows time zones, or you would use NodaTime's DateTimeZone class for IANA time zones.
In JavaScript I can do new Date().toString() which returns date time as Sun May 22 2016 02:12:36 GMT-0500 (Central Daylight Time) I can then parse the string to get "Central Daylight Time" and post it to the server.
No, this approach is not recommended, for several reasons:
There's no guarantee you will get output in any particular format from JavaScript's toString function. The results are implementation specific, and will vary across browsers and platforms.
They are generally intended for display purposes. When DST is in effect, they'll show a daylight name, and when standard time is in effect they'll show a standard name.
They are often localized for the user's language, English, French, Chinese, etc.
The only native API that can return the user's time zone is:
Intl.DateTimeFormat().resolvedOptions().timeZone
This is part of the ECMAScript Internationalization API. Unfortunately, it currently only works in a handful of browsers. Both jsTimeZoneDetect and moment.tz.guess() will use this API if it's available, then will fall back to their own guessing logic if not.
Assume that i implement timezone selection using one of the approach above and i have correct client's time zone with windows timezone id on server in some variable. Now lets say user selects 6:00 PM (Central Daylight Time , UTC -5) which will convert to UTC as 23:00:00. As long we are in Central Daylight Time the conversion from UTC to local will show 6:00 PM. Once we go into Central Standard Time which is UTC -6 Will the conversion still show 6:00 PM or 5:00 PM?
I am planning to use TimeZoneInfo.ConvertFromUtc(datetimevalue, timezone) method for converting UTC to Local
As you said earlier, "Central Daylight Time" is not a valid Windows time zone identifier. Your user wouldn't pick that. You'd display a list generated from TimeZoneInfo.GetSystemTimeZones(), showing the DisplayName to the user, and using the Id for the value. The Id would be "Central Standard Time", which indeed is the correct identifier for US Central Time, inclusive of both CST and CDT - despite having the word "Standard" in the string.
You need to convert the TimeSpan to a DateTime, using the current Year, Month and Day. If you subtract from a TimeSpan without doing so, it can result in an unobtainable date.
Also, I noticed in your update that you left the results in a DateTime, so I did the same.
This code is showing you the time if the UTC time was 1:00 AM, as your problem states.
double offset = 5.00;
TimeSpan utcTime = new TimeSpan(1,0,0); //setting manually to your representation of 1 am.
DateTime newLocalDateTime = new DateTime(DateTime.Now.Year, DateTime.Now.Month, DateTime.Now.Day, utcTime.Hours, utcTime.Minutes, utcTime.Seconds);
newLocalDateTime = newLocalDateTime.Subtract(TimeSpan.FromHours(offset));
I know this seems like a straight forward question - but although Moment.js and moment timezone are very powerful tools for getting/setting and formatting dates..
I'm having an issue snapping my application to a single timezone.
What I want, is for a user to choose from a date/time picker - and to send that as a unix timestamp in UTC.. but the date/time picker MUST be considered to be BST.
In other words, even if you're using the site from abroad - the date/time you select should be the UTC value for if you had chosen it in the UK.
var local = moment(dateTime).unix();
var london = moment(dateTime).tz('Europe/London').unix();
var berlin = moment(dateTime).tz('Europe/Berlin').unix();
All 3 variables will equal the SAME UTC timestamp on the same machine, but a different timestamp on another machine running in a different timezone.
Think about it... if my date/time was 3pm on Saturday.. that's a DIFFERENT UTC in London than it is in Berlin, since it will occur one hour earlier in Berlin.
How do I force a date/time to be considered as a specific timezone?
Thanks :-)
Assuming dateTime is an ISO8601 string, and you want the date to be in the Europe/London timezone at all times all you need is:
moment.tz(dateTime, 'Europe/London').unix()
This tells moment to interpret that time as London time, provided that it does not have a specified offset. If it has an offset, it is going to convert from the time of the offset to London time.
So, for me in America/Chicago, you can see the effect of this:
//unix timestap in london time
moment.tz('2016-12-30', 'Europe/London').unix()
1483056000
//parse that timestamp back to my local time
moment.unix(1483056000).format()
"2016-12-29T18:00:00-06:00"
Keep in mind that London has multiple offsets due to Daylight Saving Time. I think this is what you want.
If you wanted it to always keep a fixed offset of +0, then you could just use UTC:
moment.utc(dateTime)
With dateObj.toISOString().slice(0, 19).replace('T', ' ') we can convert a date object to mysql datetime format in javascript. But the timezone is always considered as the client's (browser's) timezone.
I want to convert a date and time of different time-zones (not the browser's timezone) to UTC time and then to mysql time format.
Eg:
Alice is scheduling a meeting in New-York from Sydney. Alice enters New-York time as the input. Even thought the browser's location is Sydney, the javascript code has to assume the browser's location is in New-York and convert the date time to UTC, then to mysql format.
I can get current New-York time with, dateObj.toLocaleString('en-US', { timeZone: 'America/New_York'}). But not sure what to do next. Seems to be something to do considering time differences...
Anybody knows how to do this?
So you want to always store the date in the utc representation of where the event occurred.
To Save:
You know Alice has her Time Zone set to a specific value, therefore, you need to convert from Alice's time zone to UTC. If Alice entered 11:59:59 PM for the meeting time then the time stored would be when it occurred in GMT, which would be +4/5 hours depending on whether DST is being observed. It sounds like using your solution you would need a function like dateTimeUTC=FromSpecificTimeZoneToUTC(specificTimeZoneDateTime,'Eastern Standard Time')
dateObj.toLocaleString('en-US', { timeZone: '<TimeZone name for GMT>'})
To View:
Alice now has adjusted here Time Zone info to be in PST, which is GMT-8. Since we know the event occurred at 3:59:59 AM GMT we would need a function to convert from UTC back to a specific time, PST, this would yield 7:59:59 PM in Alices' changed config.
dateTimeSpecific=FromUTCToSpecificTimeZone(uTCTimeZoneDateTime,'Pacific Standard Time')
In my opionion you might be better served handling conversions like this on the server side where you have control over the tz info. I think a js might be too inconsistent because the time information is based on the client computers regional settings, not the preferred timezone of the operation. Plus, time zone info is subject to change. I don't know how js handles those changes.