5 ms·

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

by projct 11y ago

draw_down 11y ago
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 11y ago
  Just don't do it on the front-end. Never do it on the front-end.
  - draw_down 11y ago
    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 11y ago
      You ask the user what time zone they're in? Better to have accurate data then guess.
      - redrummr 11y ago
        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.
- douche 11y ago
  Moment.js is a must-have.
  - nstr007 11y ago
    If only we didn't need to add so much to our payload just to handle dates.
- ErikAugust 11y ago
  getTimezoneOffset()
mikehollinger 11y ago
https://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 ago
  If 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 ago
  I 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.

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

by projct 11y ago

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

draw_down 11y ago

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 11y ago
Just don't do it on the front-end. Never do it on the front-end.
- draw_down 11y ago
  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 11y ago
    You ask the user what time zone they're in? Better to have accurate data then guess.
    - redrummr 11y ago
      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.
douche 11y ago
Moment.js is a must-have.
- nstr007 11y ago
  If only we didn't need to add so much to our payload just to handle dates.
ErikAugust 11y ago
getTimezoneOffset()

mikehollinger 11y ago

https://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 ago
If 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 ago
I 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.