
JavaScript's “new Date()” causing 90% of Alibaba's internal compatibility issues - mrrrgn
http://www.mrrrgn.com/20/
======
tdy721
Everything with timezones in a disaster, and the solution always seems to be a
unix timestamp that is converted to human readable form at the last possible
moment...

~~~
lightblade
Nope, use ISO 8601 format just like blog post suggested. It's more readable
and not vulnerable to the Year 2038 problem [1].

It's also important to note that ISO 8601 format is the default format that
Date object serialize to. Try it new Date().toJSON()

[1]:
[https://en.wikipedia.org/wiki/Year_2038_problem](https://en.wikipedia.org/wiki/Year_2038_problem)

~~~
cbd1984
Unix timestamps aren't vulnerable to the Year 2038 Problem unless you
deliberately make it so they are.

------
draw_down
As much as I like JS, everything involving it and dates/timezones is a giant
disaster.

~~~
projct
time is a giant disaster in every language and environment I've ever
encountered :P

~~~
draw_down
Yes. But front-end JS takes it to the next level by, for example, not
providing any sane way to get the current locale.

~~~
xlm1717
Just don't do it on the front-end. Never do it on the front-end.

~~~
draw_down
You have to. User specifies thing should happen at 2PM, their time, then POSTs
that data to your API or whatever. Well, what time are they actually talking
about? You need to know.

~~~
toomuchtodo
You ask the user what time zone they're in? Better to have accurate data then
guess.

~~~
redrummr
Especially considering this is consistent with not identifying the device
beyond headers sent etc. and you can't just use an IP address to map the
timezone as it may be shared at the tower/exchange kilometres away (DSL) or
hundreds of kilometres away (wireless/cell) and cross timezones.

The best strategy is to suggest the [timezone|local shop|city name|whatever]
and prompt for confirmation.

------
al2o3cr
My favorite is still:

    
    
        new Date('2016-02-11') !== new Date(2016,1,11)
    

One is midnight in the local TZ, other is midnight in UTC.

(╯°□°)╯︵ ┻━┻

~~~
danrisso3
Not to say that one is in February, the other in January.

~~~
rgrove
They're both in February. Months represented by integers start at 0.

    
    
        > new Date(2016,1,11)
        Thu Feb 11 2016 00:00:00 GMT-0800 (PST)
        > new Date('2016-02-11')
        Wed Feb 10 2016 16:00:00 GMT-0800 (PST)
    

I make the same mistake constantly even though I learned this years ago.

------
khgvljhkb
The french did a great job reforming measurements for weight, length, volume,
etc with the metric system.

Let's do the same for time - no more time zones, make the base unit a day and
then it can be divided or multiplied in the 10s, 100s, 1000s, etc.

~~~
meapix
Good luck with that!

~~~
khgvljhkb
If the whole world could unite with a better system of measure of space
(meter) then the same can happen for measures of time.

