js Date changes on october 10th (BST) [duplicate] - javascript

This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 5 years ago.
Why does JS Date object change toUTCString on October 10th?
new Date('2017-10-9').toUTCString()
"Sun, 08 Oct 2017 23:00:00 GMT"
new Date('2017-10-10').toUTCString()
"Tue, 10 Oct 2017 00:00:00 GMT"
I am writing these in the UK. BST ends on October 29th. What is going on?!

In the first example the date is parsed as local date, and in the second as UTC date. To parse the first date as UTC too, add a 0 before 9.
console.log(new Date('2017-10-09').toUTCString()); // Mon, 09 Oct 2017 00:00:00 GMT
Inconsistencies in date parsing like that are why you should always pass a date in ISO-8601 format to the Date constructor. You can also use a library like Moment.js.

Related

Javascript Date constructor odd behavior [duplicate]

This question already has answers here:
Ambiguous behavior of javascript new Date() constructor for same different formatted string
(3 answers)
Closed 2 months ago.
I am getting an odd behavior if I pass the Date constructor just a date string. Example:
<div>Date 1: <span id="mydate1"></span></div>
<div>Date 2: <span id="mydate2"></span></div>
<div>Date 3: <span id="mydate3"></span></div>
<script>
document.getElementById("mydate1").innerHTML = (new Date("2022-06-28 20:32:00")).toString();
document.getElementById("mydate2").innerHTML = (new Date("2022-06-28")).toString();
document.getElementById("mydate3").innerHTML = (new Date("2022-06-28 00:00:00")).toString();
</script>
This results in the following:
Date 1: Tue Jun 28 2022 20:32:00 GMT-0400 (Eastern Daylight Time)
Date 2: Mon Jun 27 2022 20:00:00 GMT-0400 (Eastern Daylight Time)
Date 3: Tue Jun 28 2022 00:00:00 GMT-0400 (Eastern Daylight Time)
Date 1 works as I would expect. But why are Date 2 and 3 different? With just a date string, it seems to be inferring the date is in UTC, where as with a time field it seems to assume it is in my locale time.
Any thoughts? I can work around it by appending the 00:00:00 text.
It is explained in the documentation of Date constructor, when the argument is a date string:
Date-only strings (e.g. "1970-01-01") are treated as UTC, while date-time strings (e.g. "1970-01-01T12:00") are treated as local.

`new Date()` parsing is format dependent [duplicate]

This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 3 years ago.
I was surprised to realize that
new Date('2015-02-15') and new Date('02-15-2015') return different results. One parses the date as midnight UTC time, the other is parsed as midnight local time. This is also true of the moment-timezone package.
Is there a way to parse these dates in a standard way, either using moment or the builtin Date?
Passing expected date string format to moment.js seem to return the same local timezone
// Sun Feb 15 2015 00:00:00 GMT-0800
moment('2015-02-15', 'YYYY-MM-DD').toString()
// Sun Feb 15 2015 00:00:00 GMT-0800
moment('02-15-2015', 'MM-DD-YYYY').toString()
You can use moment-timezone package for standardizing the time into UTC for example
// Sun Feb 15 2015 08:00:00 GMT+0000
moment('2015-02-15', 'YYYY-MM-DD').utc().toString()
// Sun Feb 15 2015 08:00:00 GMT+0000
moment('02-15-2015', 'MM-DD-YYYY').utc()toString()
Try it out: https://jsfiddle.net/wyopm3xu/

JS Date GMT + or - seems to work the wrong way round...?

Please see the code example below from Google Chrome:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500')
Result: Thu Jul 27 2017 19:10:42 GMT+0100 (BST)
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Result: Thu Jul 27 2017 09:10:42 GMT+0100 (BST)
I would read the first date current time as being 13:10 which is -0500 hours off from GMT but the result it gives is +5 hours in the future +1 hour BST. In a similar vein the second date works the opposite way being +0500 hours off but returning -5 hours in the past +1 BST.
Firefox works in a similar way but it seems without the BST:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500');
Date 2017-07-27T18:10:42.000Z
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Date 2017-07-27T08:10:42.000Z
IE Edge gives me these results:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500')
Thu Jul 27 2017 19:10:42 GMT+0100 (GMT Summer Time)
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Thu Jul 27 2017 09:10:42 GMT+0100 (GMT Summer Time)
Can anyone help throw some light on this please?
EDIT - this is not a duplicate of 'Why does Date.parse give incorrect results?' because I am not using the parse() method explicitly.
Please note: I am trying to create a date object that is not in the same timezone as my browser.
If this is not possible I might have to solve my current problem with some basic math (current time +/- the timezone required) - shame if I cannot do this with a native JS Date object.
The default conversion of a Date instance to a string gives you the date and time in terms of the local timezone. If you're doing it in the browser console, you can't even rely on that, because the console itself is free to do whatever it wants. Firefox's console seems to extract the UTC representation; if you call
new Date('Thu Jul 27 2017 13:10:42 GMT-0500').toString()
instead you get the local time.
Dates are based on the idea of UTC timestamps and the notion that local time is generally important. Creating a date from a string gives you a timestamp meaningful (well, as meaningful as possible) for the string, but subsequently the Date instance is by default treated as something relevant to the local context. You can always use the UTC APIs to extract the UTC time if you want.
This question seems to stem from unfamiliarity either with how date strings are parsed by the built–in parser or with how they are formatted by various built–in toString methods.
The same parser is used by Date.parse and the Date constructor, it doesn't matter which is used in terms of how the string is parsed to a time value. The only difference between the two is that Date.parse returns the time value as a number, whereas the Date constructor uses the time value to create a Date instance (which is the only value that a Date instance holds).
The time value itself is milliseconds since 1970-01-01T00:00:00Z, so has no time zone (and means Date instances are effectively UTC). The value returned by getTimezoneOffset and the timezone displayed in toString methods (if there is one) is from the host system, it's not a property of Date instances or the Date constructor.
The timestamp pairs in your question represent exactly the same moment in time, but in different time zones.
Thu Jul 27 2017 13:10:42 GMT-0500 is Thu Jul 27 2017 18:10:42 GMT.
Thu Jul 27 2017 19:10:42 GMT+0100 (BST) is also Thu Jul 27 2017 18:10:42 GMT.
The value returned by Date.prototype.toString is entirely implementation dependent. When you send a date to output, the host may use any method it likes to represent the Date and may format it any way it wants. In the above, it seems the host timezone (UTC+0100) has been used with the default toString, which may return a differently formatted string in different implementations.
However, recent browsers seem to have settled on RFC 2822 format. Other methods that typically return different formats are toISOString and toLocaleString (noting that all three methods could return an ISO 8601 format string and be consistent with the ECMA-262, though I don't know of any implementations that do).
The next two dates also represent exactly the same moment in time:
Thu Jul 27 2017 13:10:42 GMT+0500 is Thu Jul 27 2017 08:10:42 GMT
Thu Jul 27 2017 09:10:42 GMT+0100 (BST) is also Thu Jul 27 2017 08:10:42 GMT
Again, the host timezone has been used to generate the output string.
As for "Firefox works in a similar way but it seems without the BST", see above. ECMA-262 only requires the the format be convenient and human readable. In this case, the browser developers have chosen to use an ISO 8601 format with no offset (i.e. UTC+0000).
So:
Thu Jul 27 2017 13:10:42 GMT-0500 is Thu Jul 27 2017 18:10:42 GMT+0000
2017-07-27T18:10:42.000Z is also Thu Jul 27 2017 18:10:42 GMT+0000
The choice not to use a timezone offset is entirely up to the browser developers and is consistent with ECMA-262.
If your issue is with how date strings are parsed, the duplicate is Why does Date.parse give incorrect results?. If it's with how dates are formatted, the duplicate is Where can I find documentation on formatting a date in JavaScript? The answers to those two questions should answer any issue raised in the OP.

Reformat a date string [duplicate]

This question already has answers here:
Where can I find documentation on formatting a date in JavaScript?
(39 answers)
Closed 8 years ago.
I am working towards formatting my date and time from MON APR 08 2013 00:00:00 GMT-0400 (EASTERN DAYLIGHT TIME) to look like MON APR 08 2013 01:01:01. Although I am having no luck with everything I have tried. Can someone shed a little light. Below is the last piece of code I have tried. Thanks.
var date = new Date(parseInt(data[0].published.substr(6)));
var time = new Date(date.toLocaleDateString());
If you can, the best practice would probably be to format the date server-side, or at least present a more universally useful date (like a UNIX timestamp) instead of the formatted string.
However, if changing the server-side output is not an option, you can use the javascript date object. I see you've tried that, but you're not using the date object's constructor properly:
var dateString = 'MON APR 08 2013 00:00:00 GMT-0400 (EASTERN DAYLIGHT TIME)';
var dte = new Date(dateString);
document.write(dte.toDateString()); // output: Mon Apr 08 2013
Try it: http://jsfiddle.net/BvLkq/
If you need to reconstruct the time, you can use toLocaleDateString (docs) to pass a locale or format string, or you can build one up by hand using the getHours() (etc) functions .
Documentation
Date object on MDN - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date
Just use a simple regex.
var str = 'MON APR 08 2013 00:00:00 GMT-0400 (EASTERN DAYLIGHT TIME)';
console.log(str.replace(/(.*\d{2}\:\d{2}\:\d{2}).*$/, '$1'));
// outputs MON APR 08 2013 00:00:00

new Data in javascript returns different date [duplicate]

This question already has an answer here:
javascript Date why is the Date new Date("2011-12-13") considered a monday and not a tuesday?
(1 answer)
Closed 9 years ago.
Input: new Date("2013-03-28")
Output: Wed Mar 27 2013 17:00:00 GMT-0700 (PDT)
How do I get 28 instead of 27. Is this a javascript default issue?
When using ISO-formatted dates, either all or in-part, the timezone may be assumed to be UTC.
console.log(new Date("2013-03-28").toUTCString());
// "Thu, 28 Mar 2013 00:00:00 GMT"
To create the date in local time, you can use a different overload of the constructor (note that month is 0-indexed, so 2 is March):
console.log(new Date(2013, 2, 28).toString());
// "Thu Mar 28 2013 00:00:00 GMT-0700 (...)"

Categories