Daylight saving - past dates - javascript

I save dates as UTC in mongoDB. I already know that date object creation converts it to the local time offset according to the user's OS settings.
But let's say that in 21 aug 2020 the local offset was +8 hours and because of daylight saving in 22 aug 2020 the offset was +9.
My question is what happens to past dates I saved in the DB. The Date object will convert it to the local time as it was in the past date or it converts to the local time as for now.
Hope I explained it well. Thank you in advanced.

UTC does not have the concept of daylight savings time. DST only applies to local times.
Therefore dates that are stored in UTC are not affected by DST in any way.
Another way of looking at it is time in UTC is always continuous.
When you are converting from UTC to local time, you need to know which time zone the local time is in. Time zone is not the same thing as a UTC offset - a time zone is a rather extensive set of rules and historical transitions that define exactly what time it was in that time zone at any instant in physical time.
For example, a time zone is "America/New_York". This time zone uses two UTC offsets, -4 and -5, depending on time of year, and what year it is.

Related

How to detect add or subtract 1 hour for daylight saving in momentJS

I'm using momentJS to handle date and times in my application. All the datetime specific fields are being saved in the database as UTC format. At the time of rendering these dates, I use UTC Offset (-8.00 etc.) in momentJS like below:
moment(utcDate).utcOffset(-8.00).format()
This gives me the Pacific Time only in case of no daylight saving. But we talk about today's date, the above is not correct becasue we must have to add 1 hour of daylight saving in the offset hence it becomes -07.00.
But my problem is, how to detect and add this 1 hour in moment.
I tried moment(date).utcOffset(-8.00).isDST() which gives false all the time so not sure how to handle it.

javascript create date without daylight savings conversion

when i create date using date constructor new Date('2015','12'), it results in Fri Jan 01 2016 00:00:00 GMT-0500 (Eastern Standard Time). But don't it to assume that what date i am providing is already applied daylight conversion and create date object for december 2015, instead of jan 2016
When creating a date using the Date constructor, the time zone of the host system is almost always used (per ECMA-262). The only exception is when a number (interpreted as a time value, i.e. milliseconds since the ECMAScript epoch) is provided, or an ISO 8601 format string with a time zone. Even then, the internal time value of the Date (i.e. milliseconds since the epoch) is calculated in UTC and the host system time zone offset used for the non–UTC methods like getHours, getMinutes, etc.
Also, the timezone offset of the current systems settings are used for historical dates. So if the host is set for daylight saving, it will be applied to dates at times before daylight saving was implemented. Also, historical changes to daylight saving changeover dates and times (and even value) are not applied. The currents settings are assumed to always apply for past and future dates.
So all of the following will apply the timezone offset of the host system when creating a date for 3 February, 2016:
new Date('2/3/2016'); // US format is assumed by most browsers.
// May also create an invalid Date
new Date(2016, 1, 3); // months are zero indexed so 1 is February
new Date('2016-02-03T00:00:00'); // note missing time zone
However, the following will be treated as UTC (or invalid):
new Date('2016-02-03'); // contrary to ISO 8601, missing time zone for this
// format only is assumed to be UTC
new Date('2016-02-03T00:00:00Z'); // Note has a time zone of GMT
If you want to reliably create a Date for a specific instant in time from a string, you must provide a string with the time zone offset. Then parse it yourself since parsing of date strings is largely implementation dependent and varies across implementations. The best format to use is ISO 8601 extended so something like:
'2016-02-03T00:00:00-0800'
which represents the same instant in time no matter what the settings of the host system are. You just need to reliably parse it.
There are many good libraries for parsing and formatting, or you can write your own small functions for particular parse and output formats.

How to convert timespan using offset

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));

How to get daylight savings start and end for a time zone in Dynamics CRM?

In CRM Online 2013, I need to determine the start and end dates of daylight savings time based on a specific time zone. I have code that needs to display times converted for different time zones, aside from the time zone in the current user's settings. For example, if the current user's time zone is set to EST - Eastern Standard Time they will see date/time values in their local time, but I need to have a web resource on an entity form display that date/time converted to other time zones. I can get the standard offset for each time zone but can't find any accurate data that indicates the start month/day of daylight savings time so I know when to use that offset. Using the OData service endpoint I looked at TimeZoneDefinition and TimeZoneRule entities, and also at the user's current timezone in UserSettings entity. I checked the attributes on those entities but they have incorrect values for Daylight Savings month/day. For example, looking at EST time zone I see Daylight month and day of March 2nd, but it should be March 8.
I have verified that CRM itself works fine as expected, setting date/time values on a form result in the correct UTC value for standard time up through 3/7 and daylight savings time starting 3/8, but I need to access this same info from within a javascript web resource. Any help is much appreciated.
I think I just realized what the issue is. I was expecting the values to be defined as the specific month and day (as in day of the month) when daylight savings starts. I believe that the day value (DaylightDay or TimeZoneDaylightDay depending on what entity you're looking at) is part of the standard rule definition for Daylight Savings Time. A day value of 2 really means the second occurrence of that day in the month, and needs to be taken along with DaylightDayOfWeek value. For example, if the month is 3, day is 2, and day of week is 0, this would be read as the second(2) Sunday(0) in March(3). That makes sense now that I see it, this is just the rule that can be used to calculate the actual start of DST in any given year.

Convert unix timestamp with a timezone to javascript date

I have a legacy web app that stores dates as a UNIX timestamp (seconds since the epoch 1970). Usually a timestamp like this represents UTC, however these timestamps are UTC-8. It doesn't look like it ever accounts for Daylight Savings Time (DST). I could convert it on the server to UTC and send to the client, but I would like to know if there is a javascript only solution.
Example Input:
1399335987
Example Output:
"2014-05-05T16:26:27-07:00" // Pacific Daylight Time (PDT)
The client should display the date/time according to their local machine. I looked into using momentjs but I could not find how to construct a date from a number without the number being UTC already. Is this possible?
Yes, it's possible given the unix timestamps are in UTC, with Moment Timezone (http://momentjs.com/timezone/)
moment
.unix(1399335987)
.tz('MST')
.format('YYYY-MM-DDTHH:mm:ssZ');
And you get
"2014-05-05T17:26:27-07:00"
Note here I'm using MST, and you should be able to use whatever timezone you want, via Timezone Data Builder (http://momentjs.com/timezone/data/)
Actually, by default, moment parses and displays in local time.
This means, only if you're in a different timezone (offset really) and still want to get the local time in MST, it's necessary to set the timezone as MST.
Otherwise, moment.unix(1399335987).format('YYYY-MM-DDTHH:mm:ssZ') is good to go.

Categories