4 ms·

time handling is rough, but a rule of thumb is to use absolute time (e.g. UTC timestamps, datetime with tz offset) for things that represent a concrete point in

by hnav 3y ago

time handling is rough, but a rule of thumb is to use absolute time (e.g. UTC timestamps, datetime with tz offset) for things that represent a concrete point in time (especially if they've already happened) and use time in a timezone (not an offset) to represent future events. In this case you'd store 9AM on this date, in this timezone, then lookup the absolute offset closer to when you need it.

kelnos 3y ago
That technically doesn't work; you have to store the location, not the time zone. Standard time and DST are actually two different time zones (and are represented as such in software); if you were doing your scheduling in January, and said "9am on July 8th in the current time zone", then the event would get translated to the wrong time when July arrives (because "current time zone" in January is standard time, while in July it'd be DST). If you instead just specify a location, then the hour number for the time always remains the same, and the time zone gets inferred from the location. This also saves you from the possibility that DST rules might change for that location in the future, or that there might be a more major reshuffle, and the location gets moved to an entirely new time zone. (Like, for example, say the Chinese central government decides to stop being shitty to most of their country and allows the central and western areas of the country to be on a different time zone from Beijing.)
- SAI_Peregrinus 3y ago
  But whatever you do don't assume the location must be the user's current location.
- hnav 3y ago
  timezones as in IANA tzdb[0], not offsets from UTC. The terminology is confusing. [0] https://en.wikipedia.org/wiki/List_of_tz_database_time_zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
happytoexplain 3y ago
I don't think future vs past is a good distinction. There is really not a succinct rule of thumb (the common one, "just use UTC", can mean multiple things and can mislead juniors), which is a symptom of the conceptual complexity of distinguishing time as a physical measure vs time as a cultural construct. This is compounded severely by the insistence of many languages, libraries, and platforms of calling absolute times "Dates" and reinforcing that lie by silently picking arbitrary tz offsets to add to your absolute times at API edges - perhaps the single most destructive cutesy convenience in the history of software. The only real rule of thumb is: If the clock time, calendar date, or tz offset matter in your use case, store them. Otherwise, use absolute time. Learn how your platform stores time and then you will see where your tools are doing the conversion for you, and STOP them from doing it.

by hnav 3y ago

kelnos 3y ago

That technically doesn't work; you have to store the location, not the time zone. Standard time and DST are actually two different time zones (and are represented as such in software); if you were doing your scheduling in January, and said "9am on July 8th in the current time zone", then the event would get translated to the wrong time when July arrives (because "current time zone" in January is standard time, while in July it'd be DST). If you instead just specify a location, then the hour number for the time always remains the same, and the time zone gets inferred from the location. This also saves you from the possibility that DST rules might change for that location in the future, or that there might be a more major reshuffle, and the location gets moved to an entirely new time zone. (Like, for example, say the Chinese central government decides to stop being shitty to most of their country and allows the central and western areas of the country to be on a different time zone from Beijing.)

SAI_Peregrinus 3y ago
But whatever you do don't assume the location must be the user's current location.
hnav 3y ago
timezones as in IANA tzdb[0], not offsets from UTC. The terminology is confusing. [0] https://en.wikipedia.org/wiki/List_of_tz_database_time_zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

happytoexplain 3y ago

I don't think future vs past is a good distinction. There is really not a succinct rule of thumb (the common one, "just use UTC", can mean multiple things and can mislead juniors), which is a symptom of the conceptual complexity of distinguishing time as a physical measure vs time as a cultural construct. This is compounded severely by the insistence of many languages, libraries, and platforms of calling absolute times "Dates" and reinforcing that lie by silently picking arbitrary tz offsets to add to your absolute times at API edges - perhaps the single most destructive cutesy convenience in the history of software. The only real rule of thumb is: If the clock time, calendar date, or tz offset matter in your use case, store them. Otherwise, use absolute time. Learn how your platform stores time and then you will see where your tools are doing the conversion for you, and STOP them from doing it.