5 ms·

You shouldn't be putting timezones in your datetimes. Always use UTC until the point you're actually displaying something to a human.

mattmanser 9y ago
If I have a booking at a restaurant in France tomorrow for 8pm local time, and live in the UK, why should I convert that to UTC? It would also show the wrong time in the client! Not only would the time be wrong, but I have to make it right I then have to send extra data about the restaurant and do extra work on the client to show the correct time. It doesn't even make sense to do that. There are both advantages and disadvantages to UTC dates vs relative ones, humans almost exclusively use relative dates and that makes it hard to justify using UTC everywhere.
- itamarst 9y ago
  You still shouldn't store timezone in that case. It presumes you can know in advance what timezone will be in particular place at particular future date. But there's daylight savings time, and e.g. in Israel start date of daylight savings used to depend on result of elections. Seriously. So, for your use case you want to store timezone-free time + location, since dinner appointment would happen at 8 regardless of DST.
  - mattmanser 9y ago
    You misunderstood, that's my point. If you send it in ISO8601 as a UTC date, it's always wrong in that scenario. If you leave off the Z, browsers all do different weird things (and worse, Chrome recently changed how the interpret ISO8601 dates without a Z). But if you send it in yyyy/MM/dd hh:mm:ss format, a format supported by all JS clients, it's unambiguously a relative date and won't be interpreted incorrectly by the browser. Annoyingly, moment.js seem to be threatening to drop support for that format.
    - iDemonix 9y ago
      Why overcomplicate when a UTC timestamp works perfectly and takes up less space?
fulafel 9y ago
It's a necessary part of human-readability, for one.

mattmanser 9y ago

If I have a booking at a restaurant in France tomorrow for 8pm local time, and live in the UK, why should I convert that to UTC? It would also show the wrong time in the client! Not only would the time be wrong, but I have to make it right I then have to send extra data about the restaurant and do extra work on the client to show the correct time. It doesn't even make sense to do that. There are both advantages and disadvantages to UTC dates vs relative ones, humans almost exclusively use relative dates and that makes it hard to justify using UTC everywhere.

itamarst 9y ago
You still shouldn't store timezone in that case. It presumes you can know in advance what timezone will be in particular place at particular future date. But there's daylight savings time, and e.g. in Israel start date of daylight savings used to depend on result of elections. Seriously. So, for your use case you want to store timezone-free time + location, since dinner appointment would happen at 8 regardless of DST.
- mattmanser 9y ago
  You misunderstood, that's my point. If you send it in ISO8601 as a UTC date, it's always wrong in that scenario. If you leave off the Z, browsers all do different weird things (and worse, Chrome recently changed how the interpret ISO8601 dates without a Z). But if you send it in yyyy/MM/dd hh:mm:ss format, a format supported by all JS clients, it's unambiguously a relative date and won't be interpreted incorrectly by the browser. Annoyingly, moment.js seem to be threatening to drop support for that format.
  - iDemonix 9y ago
    Why overcomplicate when a UTC timestamp works perfectly and takes up less space?

fulafel 9y ago

It's a necessary part of human-readability, for one.