This question already has answers here:
Browsers, time zones, Chrome 67 Error (historic timezone changes)
(2 answers)
Closed 4 years ago.
I have 2 questions.
1. Regarding daylight saving time implementation in JavaScript in browsers.
( Output is from Chrome Browser)
var dt1 = new Date(1975, 1 , 23, 1, 0, 0);
dt1.toString(); // Sun Feb 23 1975 01:00:00 GMT-0600 (Central Standard Time)
dt1.toUTCString(); // Sun, 23 Feb 1975 07:00:00 GMT
dt1.getTime(); // 162370800000
var dt2 = new Date(1975, 1 , 23, 2, 0, 0);
dt2.toString(); // Sun Feb 23 1975 03:00:00 GMT-0500 (Central Daylight Time)
dt2.toUTCString(); // Sun, 23 Feb 1975 08:00:00 GMT
dt2.getTime(); //162374400000
var dt3 = new Date(1975, 1 , 23, 3, 0, 0);
dt3.toString(); // Sun Feb 23 1975 03:00:00 GMT-0500 (Central Daylight Time)
dt3.toUTCString(); // Sun, 23 Feb 1975 08:00:00 GMT
dt3.getTime(); // 162374400000
For the date objects dt2 and dt3, observe all the values are same. This is confusing.
2. Internet explorer has wrong daylight saving time start dates.
In year 1975, daylight saving time stared on date Feb 23 1975 2:00 AM.
When I create date objects for dates Feb 23 1975 1AM, 2 AM and Apr 6 1975 1AM, 2AM, 3AM in Chrome and IE...
Feb 23 1975 1AM
Chrome: Sun Feb 23 1975 01:00:00 GMT-0600 (Central Standard Time)
IE : Sun Feb 23 1975 01:00:00 GMT-0600 (Central Standard Time)
Feb 23 1975 2AM
Chrome: Sun Feb 23 1975 03:00:00 GMT-0500 (Central Daylight Time)
IE : Sun Feb 23 1975 02:00:00 GMT-0600 (Central Standard Time)
Apr 6 1975 1AM
Chrome: Sun Apr 06 1975 01:00:00 GMT-0500 (CDT) //165996000000
IE : Sun Apr 06 1975 01:00:00 GMT-0600 (CST) //165999600000. Time in milliseconds is also different.
Apr 6 1975 2AM
Chrome: Sun Apr 06 1975 02:00:00 GMT-0500 (CDT) // 165999600000
IE : Sun Apr 06 1975 01:00:00 GMT-0600 (CST) // 165999600000. Time in milliseconds is same.
Apr 6 1975 3AM
Chrome: Sun Apr 06 1975 03:00:00 GMT-0500 (CDT)
IE : Sun Apr 06 1975 03:00:00 GMT-0500 (CDT)
In IE for year 1975, daylight saving time logic starts after Apr 6 1975 2PM and not after Feb 23 1975 2AM as it is supposed to be. Chrome is working properly.
How do I show proper date string in all browsers when daylight saving time is involved?
Daylight savings and timezones are the worst! :)
JavaScript Date/Time is always subject to the idiosyncrasies of each and every browser as it runs client side. So even 2 users with identical browsers may get variations based on their laptop settings.
To specifically answer the 2 questions in your post:
1: Looks like you are accessing the JavaScript from the Central Timezone which observes DST whereas UTC doesn't. Daylight savings time occurs at 2am, so dt1 will be in standard time as it is 1am on that that evening, where as dt2 & dt3 are in dst as they are 2am and 3am respectively. That's the reason for the difference.
2: Because Richard Nixon infamously mandated year-round daylight saving in 1974 and 1975. Appears the version of IE you are testing with handles the DST based on the executive mandate at the time, whereas Chrome applies it in a consistent format based on current guidelines.
Fortunately there is MomentJS and MomentTimezone which handles all these variations: Is moment.js browser independent?
These are essential JavaScript libraries for anything related to Date/Time
https://momentjs.com/
https://momentjs.com/timezone/
Easiest way to get going is:
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.22.2/moment.min.js"> </script>
<script>
var now = moment();
console.log(now.format());
console.log(now.isDST());
</script>
You can place that inside your bodytag and look in the console and it'll be working for you. Have fun!
Related
I have what seems like a very common use case: I want to have a recurring event that occurs at the same time each day in a specific time zone (in the example below, 6:00 AM in the America/Denver time zone). I want this to recur at the same time of day after a change in Daylight Savings as before. Right now, it is changing by one hour after Daylight Savings, which seems to indicate that Daylight Savings is not being accounted for when the recurring datetimes are generated.
I have tried various configurations for the rrule as indicated in the documentation here and here. It says the time of day should be the same across Daylight Savings, but that is not what I am seeing.
Code sample
const rrule = new RRule({
freq: RRule.DAILY,
dtstart: new Date(Date.UTC(2022, 7, 18, 12, 0, 0)),
// tzid: 'America/Denver', // output is the same whether this is included or not
})
const datetimes = rrule.between(
new Date('2022-10-31'),
new Date('2022-11-10')
)
Try out the CodeSandbox. Should get similar results as long as you are in a time zone that has Daylight Savings and the between range includes a change in Daylight Savings.
Expected output
The time of day in America/Denver time zone should not change after Daylight Savings (i.e. recurrence should account for Daylight Savings):
Mon Oct 31 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Tue Nov 01 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Wed Nov 02 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Thu Nov 03 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Fri Nov 04 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Sat Nov 05 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Sun Nov 06 2022 06:00:00 GMT-0700 (Mountain Standard Time) <-- Daylight savings change
Mon Nov 07 2022 06:00:00 GMT-0700 (Mountain Standard Time)
Tue Nov 08 2022 06:00:00 GMT-0700 (Mountain Standard Time)
Wed Nov 09 2022 06:00:00 GMT-0700 (Mountain Standard Time)
^^
Actual output
The time of day in America/Denver time zone is changing from 6:00 to 5:00:
Mon Oct 31 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Tue Nov 01 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Wed Nov 02 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Thu Nov 03 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Fri Nov 04 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Sat Nov 05 2022 06:00:00 GMT-0600 (Mountain Daylight Time)
Sun Nov 06 2022 05:00:00 GMT-0700 (Mountain Standard Time) <-- Daylight savings change
Mon Nov 07 2022 05:00:00 GMT-0700 (Mountain Standard Time)
Tue Nov 08 2022 05:00:00 GMT-0700 (Mountain Standard Time)
Wed Nov 09 2022 05:00:00 GMT-0700 (Mountain Standard Time)
^^
I've opened an issue for this on GitHub, but I'm wondering if I'm just missing something. It seems like a common use case, so I would think I'd be able to find something out there about it. I did find a couple of SO questions about it here and here, but I'm already applying the solutions suggested.
Is this an actual bug in rrule or am I just missing something?
I had to dig very deep and surprisingly it seems like there is no bug. If you change your CodeSandbox to the following then it should work:
import { RRule } from "rrule";
import "./styles.css";
const rrule = new RRule({
freq: RRule.DAILY,
dtstart: new Date(Date.UTC(2022, 7 - 1, 18, 12, 0)), // See note 1
tzid: 'America/Denver',
})
const datetimes = rrule.between(
new Date('2022-10-31'),
new Date('2022-11-10')
)
const output = datetimes.map((d) => new Date( // See note 2
d.getUTCFullYear(),
d.getUTCMonth(),
d.getUTCDate(),
d.getUTCHours(),
d.getUTCMinutes(),
)).join('<br/>')
document.getElementById("app").innerHTML = output;
Notes:
The docs at https://github.com/jakubroztocil/rrule#timezone-support state that using new Date(2022, 7, ...) will produce unexpected timezone offsets. Instead use rrule's datetime function. Since this function currently is not working (see https://github.com/jakubroztocil/rrule/issues/551) we have to use new Date(Date.UTC(2022, 7 - 1, ...)) (which is excatly what the datetime function is doing).
The result will be a date in UTC which you have to interpret as a date in the timezone you specified in tzid. It seems very weird but it is stated in the docs at https://github.com/jakubroztocil/rrule#important-use-utc-dates that: Even though the given offset is Z (UTC), these are local times, not UTC times. Just to emphasize this my code example transforms the UTC dates to America/Denver dates by creating a new instance of Date using the UTC values (only works if your operating's system timezone is America/Denver).
I am in London (GMT time zone). We are currently in DST.
In the UK, Daylight Saving Time starts in March and ends in October, so Jan 1 1970 would have been outside DST.
However,
epochDate = new Date(0);
console.log(epochDate);
returns
Thu Jan 01 1970 01:00:00 GMT+0100 (Greenwich Mean Time)
I expected
Thu Jan 01 1970 00:00:00 GMT+0000 (Greenwich Mean Time)
Does Date(); return results in the current timezone?!
JavaScript Date(0) returns GMT+1 because, according to Wikipedia (and timeanddate.com), "the British Standard Time experiment, with Britain remaining on GMT+1 throughout the year… took place between 27 October 1968 and 31 October 1971"
I am using datepicker with localization.
It all works great but i have a problem.
var selected_date = jQuery('.datepicker').datepicker('getDate');
selected_date = new Date(selected_date);
Output on Chrome :
Wed Oct 24 2018 00:00:00 GMT+0300 (Eastern European Summer Time)
Output on IE 11 :
Wed Oct 24 2018 00:00:00 GMT+0300 (GTB Summer Time)
How is that possible happening in same server, same time and same conditions.
This question already has answers here:
Browsers, time zones, Chrome 67 Error (historic timezone changes)
(2 answers)
Closed 4 years ago.
I have an application which allows users to pick some time slots. By default the timeslots are empty, and my .NET back-end has default generated values of type DateTimeOffset, which by default are set to "0001-01-01T00:00:00+00:00".
Now, when I populate a date on the front-end with this value, it generates a date in the local time zone, but with wrong minutes and seconds. This happens only in Chrome. I'm not seeing this under Edge or Firefox.
console.log(new Date("2001-01-01T00:00:00+00:00").toString())
// Mon Jan 01 2001 02:00:00 GMT+0200 (Eastern European Standard Time)
console.log(new Date("1001-01-01T00:00:00+00:00").toString())
//Thu Jan 01 1001 02:02:04 GMT+0202 (Eastern European Standard Time)
console.log(new Date("1801-01-01T00:00:00+00:00").toString())
//Thu Jan 01 1801 02:02:04 GMT+0202 (Eastern European Standard Time)
console.log(new Date("1901-01-01T00:00:00+00:00").toString())
//Tue Jan 01 1901 02:02:04 GMT+0202 (Eastern European Standard Time)
console.log(new Date("1961-01-01T00:00:00+00:00").toString())
//Sun Jan 01 1961 03:00:00 GMT+0300 (Eastern European Standard Time)
console.log(new Date("1921-01-01T00:00:00+00:00").toString())
//Sat Jan 01 1921 02:02:04 GMT+0202 (Eastern European Standard Time)
console.log(new Date("1931-01-01T00:00:00+00:00").toString())
//Thu Jan 01 1931 03:00:00 GMT+0300 (Eastern European Standard Time)
console.log(new Date("1922-01-01T00:00:00+00:00").toString())
//Sun Jan 01 1922 02:02:04 GMT+0202 (Eastern European Standard Time)
console.log(new Date("1923-01-01T00:00:00+00:00").toString())
//Mon Jan 01 1923 02:02:04 GMT+0202 (Eastern European Standard Time)
console.log(new Date("1924-01-01T00:00:00+00:00").toString())
//Tue Jan 01 1924 02:02:04 GMT+0202 (Eastern European Standard Time)
console.log(new Date("1925-01-01T00:00:00+00:00").toString())
//Thu Jan 01 1925 02:00:00 GMT+0200 (Eastern European Standard Time)
As you can see, I played around with the date, to see before which date this happens, but the problem may not be the year 1925, just certain time before the current date. Does anyone know why this is happening?
Screenshot as requested
Prior to 1883 Time Zones were not standardized. If you check every year you'll notice that 1883 is "broken" with the additional minutes and 1884 is "fine". Chrome handles this transition very well - you'll notice the "problem" doesn't exist in Firefox.
new Date("1883-01-01T00:00:00+00:00")
Sun Dec 31 1882 16:07:02 GMT-0752 (Pacific Standard Time)
new Date("1884-01-01T00:00:00+00:00")
Mon Dec 31 1883 16:00:00 GMT-0800 (Pacific Standard Time)
In fact, you can track this down to November 18th, 1883.
new Date("1883-11-18T00:00:00+00:00")
Sat Nov 17 1883 16:07:02 GMT-0752 (Pacific Standard Time)
new Date("1883-11-19T00:00:00+00:00")
Sun Nov 18 1883 16:00:00 GMT-0800 (Pacific Standard Time)
Chrome tries very hard to match time, even going so far as to calculate the suspended DST of Ramadan in Egypt in 2010.
Read more here: https://www.huffingtonpost.com/quora/how-when-and-why-were-tim_b_5838042.html
My dev environment is in mac.
I use bootstrap datepicker to choose dates in an application.
When a day like 27/11/2013 is selected in mac when I debug, the screen shows...
day: 1385510400
and the translation to an date object in the same debug tool is,
Wed Nov 27 2013 00:00:00 GMT+0000 (GMT)
which is correct.
All is OK, since here.
I upload the code to a windows environment and open the same page with IE8.
Start the nightmare... :)
In windows, the same day variable is shown like that...
day: 1385506800
and the translation to an date object in the same debug tool is,
Wed Nov 27 2013 00:00:00 GMT+0000 (GMT)
which, is not correct?
If we go to a external tool, the day that gave IE8 is day before, and the translation should be,
Tue, 26 Nov 2013 23:00:00 GMT.
How I can understand this?
There is no relation with the timestamp and the translation to date object, and obviously I can't find a way to make this works in both systems.
Could you wake me up from this nightmare?
Sorry for my english!
Fiddle
In JS in Chrome:
new Date(1385510400000) : Wed Nov 27 2013 01:00:00 GMT+0100
new Date(1385506800000) : Wed Nov 27 2013 00:00:00 GMT+0100
new Date("11/27/2013") : Wed Nov 27 2013 00:00:00 GMT+0100
Please note the order of the date string, it is in US order
Also note the 000 at the end; JS timestamps are in milliseconds
The same in IE8
Wed Nov 27 01:00:00 UTC+0100 2013
Wed Nov 27 00:00:00 UTC+0100 2013
Wed Nov 27 00:00:00 UTC+0100 2013
So exactly the same dates, on hour difference on the first
If you subtract the 1 hour from all dates, you get midnight on the first and 11pm on the 26th on the rest
To normalise you can do
var d = new Date(1385510400000);
d.setHours(0,0,0);
or change to UTC