For this particular project, I haven't even written JS code yet. It has all been in Elm. However, Elm's Date.fromString string function calls this JS under the covers: new Date( string ). So it is important to know the behavior. I ran these bits from the browser console.
In this case, example 2 is the one I prefer. Because it is a way to store/transmit a date that will parse to the right day regardless of the current time zone. So hopefully it would not be a linting error.
In an ideal world I would just work with UTC dates, but JS Date can only be made in the local time zone. Working in non-local time zones must be done with something other than JS Date (e.g. unix epoch integer, moment.js, etc).
Nope, it does not work. Date.UTC returns unix epoch time (milliseconds since UTC midnight on 1 Jan 1970) as an integer. When you use that to construct a new Date it will still be converted to the local time zone.
// zero-based months 🙄newDate(Date.UTC(2018,0/* Jan */,1))<-SunDec31201718:00:00GMT-0600(CentralStandardTime)
The only reason the linked example prints GMT time zone is because Date.toUTCString() is used. But when using the JS Date object, calculations will be off by a day behind in my local time zone.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For this particular project, I haven't even written JS code yet. It has all been in Elm. However, Elm's
Date.fromString stringfunction calls this JS under the covers:new Date( string ). So it is important to know the behavior. I ran these bits from the browser console.In this case, example 2 is the one I prefer. Because it is a way to store/transmit a date that will parse to the right day regardless of the current time zone. So hopefully it would not be a linting error.
In an ideal world I would just work with UTC dates, but JS Date can only be made in the local time zone. Working in non-local time zones must be done with something other than JS Date (e.g. unix epoch integer, moment.js, etc).
For UTC dates, is developer.mozilla.org/en-US/docs/W... not a possibility?
Nope, it does not work.
Date.UTCreturns unix epoch time (milliseconds since UTC midnight on 1 Jan 1970) as an integer. When you use that to construct anew Dateit will still be converted to the local time zone.The only reason the linked example prints GMT time zone is because
Date.toUTCString()is used. But when using the JS Date object, calculations will be off by a day behind in my local time zone.