6 ms·
JavaScript's “new Date()” causing 90% of Alibaba's internal compatibility issues
- draw_down 11y agoAs much as I like JS, everything involving it and dates/timezones is a giant disaster.
- projct 11y agotime is a giant disaster in every language and environment I've ever encountered :P
- draw_down 11y agoYes. But front-end JS takes it to the next level by, for example, not providing any sane way to get the current locale.
- xlm1717 11y agoJust don't do it on the front-end. Never do it on the front-end.
- draw_down 11y agoYou 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 11y agoYou ask the user what time zone they're in? Better to have accurate data then guess.
- redrummr 11y agoEspecially 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.
- douche 11y agoMoment.js is a must-have.
- nstr007 11y agoIf only we didn't need to add so much to our payload just to handle dates.
- ErikAugust 11y agogetTimezoneOffset()
- mikehollinger 11y agohttps://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY is a pretty entertaining video that talks about the various hoops developers must jump through.
- douche 11y agoIf you haven't seen this, you should. Quite possibly my favorite youtube video, and this channel has a number of other great clips.
- com2kid 11y agoI work in embedded. We have to do this on our own. It is every bit as painful as it is made out to be. A common problem that I don't see discussed much is the difference between recording when a time took place (just record and store it in UTC!) and then translating that into what the user expects to see. This is especially hard if you have information that should be grouped into "days", and a use case where the user changes time zones but may expect the same "relative to originally recorded time" to be shown when viewing past events. A nightmare case.
- tdy721 11y agoEverything 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 11y agoNope, 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 11y agoUnix timestamps aren't vulnerable to the Year 2038 Problem unless you deliberately make it so they are.
- tdeck 11y agoThe problem with ISO 8601 is that it isn't as simple as it looks. A lot of implementations that claim to support ISO 8601 do not parse all the different formats allowed by the standard. There are all kinds of weird edge cases like specifying a date with a year and week number that are valid. RFC3339 defines a subset that is only the sane tinestamp format most people probably think of when they think ISO8601. It's a good alternative, although a lot of the time UNIX timestamps are honestly the most convenient option for everyone. Source: spent a bunch of time designing a public API and thinking about this.
- deleted 11y ago[deleted]
- kbart 11y ago"It's more readable and not vulnerable to the Year 2038 problem" What makes you use signed 32-bit Integer for Unix timestamp in this age and day? I work with embedded systems and use Unix timestamp extensively, but never have I found any serious reason to use it as int32_t.
- khgvljhkb 11y agoThe 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.
- al2o3cr 11y agoMy 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 11y agoNot to say that one is in February, the other in January.
- rgrove 11y agoThey'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.