4 ms·

If your application is future-dating items, like say clients entering appointments in a calendar, this will be very wrong. If a customer enters an appointment

If your application is future-dating items, like say clients entering appointments in a calendar, this will be very wrong. If a customer enters an appointment 6 months in the future, it will end up at the wrong time due to daylight savings time. UTC is great for timestamps (when did this event happen) but not good for user-entered dates. You throw away useful information if you store in UTC.

deleted 7y ago
[deleted]
wil421 7y ago
You store the offset or you store the users configuration. Use the users config and/or offset to convert it from UTC. There should be a way to account for DST. I’ll look into it when I get a chance. If the future date was input in EDT or EST you’d know what to do in the future when you convert back to either EDT or EST based on the time of year.
- wvenable 7y ago
  You can do a lot of things but, at some point, you have to ask yourself if the solution is signficantly more complex than storing local time and the timezone. You also need to be aware that timezones change; even now there are discussions about eliminating daylight saving time in various regions. If you store 4:00pm on Nov 25th and convert that to UTC based on the timezone rules as they exist today, you'll be wrong when you convert them back under different timezone rules. There's just no way to do that cleanly. There are also things to consider: if the user changes their own timezone (by moving) did they intend the value of that time to change (4:00pm is now 1:00pm because it's a WebEx and they moved East) or did they intend that to remain at 4:00pm (it's when they take their medicine every day).
dragonwriter 7y ago
> If your application is future-dating items, like say clients entering appointments in a calendar, this will be very wrong. Well, the future has problems no matter what you do. > If a customer enters an appointment 6 months in the future, it will end up at the wrong time due to daylight savings time. No, becauae that you store UTC doesn't mean that you also convert entries to UTC using the offset on the entry date without looking at the date the time is attached to. OTOH, no matter what you store, the fact that DST rules and even timezone boundaries can change over time means that you have to store a lot more about the intent than just the time to be certain of being correct for future times. Did you want X time in Y time zone or X time in the legal time applicable to Z venue? The former is often used as a proxy forthe latter on the assumption that tim zones don't change...
- deleted 7y ago
  [deleted]
dheera 7y ago
No. ALWAYS store user-entered dates in UTC, and simultaneously either (a) save the user's timezone preference or (b) use their system-specified timezone and only do that conversion at the last step when rendering the UI, preferably with client-side timezone functions. Also use client-side timezone functions to provide the server with UTC dates directly. You'll deal with DST hell on your server otherwise. Countries change their DST and timezone policies from time to time, and you don't want to have to deal with keeping track of that stuff or force upgrading your server for a petty politician/timezone issue. That's the client machine's job. Saving everything in UTC also makes comparisons, logging, abuse tracking much easier.
- wvenable 7y ago
  If you use the client's timezone preference to store the date and then use the client's timezone preference to recover the date at a future date, you might still mess it up (from the user perspective). It depends on the user's intent. If they book something at 4:00pm 2 years from now, will that become 5:00pm if the timezone rules change or stay at 4:00pm. I'd argue that for most future-dated items it should stay at 4:00pm. The only way to guarantee that is store the local time. Storing UTC doesn't relieve you of timezone problems.
- stouset 7y ago
  Future times record intent, which requires storing a datetime (sans any kind of time zone information) and location. Past times can be stored as a UTC timestamp. Storing and using a time zone for points in the future is the path of madness. If a user has an event at 2pm six months from now, they almost certainly want that event to be at 2pm no matter what the UTC offset happens to be on that day. This becomes even more obvious for repeating events: an event at 2pm this week will still be at 2pm six months from now, even after DST flips. And even if my government decides to change the time zone my location is in, or decided to opt into/out of DST.
  - lhorie 7y ago
    > If a user has an event at 2pm six months from now, they almost certainly want that event to be at 2pm no matter what the UTC offset happens to be on that day Not necessarily. If the event is a long distance meeting that span multiple timezones, then by definition, the event isn't going to be at 2pm for all consumers of that data. Location is kind of a proxy for timezone, but it makes more sense to just let the client's OS figure the offset from UTC time than to manually manage timezones in the server yourself. Similarly, you let the client tell the server what timestamp "2pm two weeks from now" is (letting it consult its OS' timezone database to figure out what that means for the user's chosen geographic location), rather than trying to naively add up the seconds from now to then in the server. Saving the user's location in your DB to compute offsets on the server is problematic because you can't always get geographic data from the client (e.g. browsers will readily make timezone available to Javascript, but geolocation data might be unobtainable due to permissions/privacy concerns/etc). Also, users may move/travel, so getting geo data from side channels such as sign up forms also could lead to discrepancies.
deleted 7y ago
[deleted]

deleted 7y ago

[deleted]

wil421 7y ago

You store the offset or you store the users configuration. Use the users config and/or offset to convert it from UTC. There should be a way to account for DST. I’ll look into it when I get a chance. If the future date was input in EDT or EST you’d know what to do in the future when you convert back to either EDT or EST based on the time of year.

wvenable 7y ago
You can do a lot of things but, at some point, you have to ask yourself if the solution is signficantly more complex than storing local time and the timezone. You also need to be aware that timezones change; even now there are discussions about eliminating daylight saving time in various regions. If you store 4:00pm on Nov 25th and convert that to UTC based on the timezone rules as they exist today, you'll be wrong when you convert them back under different timezone rules. There's just no way to do that cleanly. There are also things to consider: if the user changes their own timezone (by moving) did they intend the value of that time to change (4:00pm is now 1:00pm because it's a WebEx and they moved East) or did they intend that to remain at 4:00pm (it's when they take their medicine every day).

dragonwriter 7y ago

> If your application is future-dating items, like say clients entering appointments in a calendar, this will be very wrong. Well, the future has problems no matter what you do. > If a customer enters an appointment 6 months in the future, it will end up at the wrong time due to daylight savings time. No, becauae that you store UTC doesn't mean that you also convert entries to UTC using the offset on the entry date without looking at the date the time is attached to. OTOH, no matter what you store, the fact that DST rules and even timezone boundaries can change over time means that you have to store a lot more about the intent than just the time to be certain of being correct for future times. Did you want X time in Y time zone or X time in the legal time applicable to Z venue? The former is often used as a proxy forthe latter on the assumption that tim zones don't change...

deleted 7y ago
[deleted]

dheera 7y ago

No. ALWAYS store user-entered dates in UTC, and simultaneously either (a) save the user's timezone preference or (b) use their system-specified timezone and only do that conversion at the last step when rendering the UI, preferably with client-side timezone functions. Also use client-side timezone functions to provide the server with UTC dates directly. You'll deal with DST hell on your server otherwise. Countries change their DST and timezone policies from time to time, and you don't want to have to deal with keeping track of that stuff or force upgrading your server for a petty politician/timezone issue. That's the client machine's job. Saving everything in UTC also makes comparisons, logging, abuse tracking much easier.

wvenable 7y ago
If you use the client's timezone preference to store the date and then use the client's timezone preference to recover the date at a future date, you might still mess it up (from the user perspective). It depends on the user's intent. If they book something at 4:00pm 2 years from now, will that become 5:00pm if the timezone rules change or stay at 4:00pm. I'd argue that for most future-dated items it should stay at 4:00pm. The only way to guarantee that is store the local time. Storing UTC doesn't relieve you of timezone problems.
stouset 7y ago
Future times record intent, which requires storing a datetime (sans any kind of time zone information) and location. Past times can be stored as a UTC timestamp. Storing and using a time zone for points in the future is the path of madness. If a user has an event at 2pm six months from now, they almost certainly want that event to be at 2pm no matter what the UTC offset happens to be on that day. This becomes even more obvious for repeating events: an event at 2pm this week will still be at 2pm six months from now, even after DST flips. And even if my government decides to change the time zone my location is in, or decided to opt into/out of DST.
- lhorie 7y ago
  > If a user has an event at 2pm six months from now, they almost certainly want that event to be at 2pm no matter what the UTC offset happens to be on that day Not necessarily. If the event is a long distance meeting that span multiple timezones, then by definition, the event isn't going to be at 2pm for all consumers of that data. Location is kind of a proxy for timezone, but it makes more sense to just let the client's OS figure the offset from UTC time than to manually manage timezones in the server yourself. Similarly, you let the client tell the server what timestamp "2pm two weeks from now" is (letting it consult its OS' timezone database to figure out what that means for the user's chosen geographic location), rather than trying to naively add up the seconds from now to then in the server. Saving the user's location in your DB to compute offsets on the server is problematic because you can't always get geographic data from the client (e.g. browsers will readily make timezone available to Javascript, but geolocation data might be unobtainable due to permissions/privacy concerns/etc). Also, users may move/travel, so getting geo data from side channels such as sign up forms also could lead to discrepancies.

deleted 7y ago

[deleted]