4 ms·

If you watch the video I linked above, he explicitly mentions that 99% of the time you should not be dealing with any of those things manually - that if you fin

If you watch the video I linked above, he explicitly mentions that 99% of the time you should not be dealing with any of those things manually - that if you find yourself working with offsets and DST values, it's a sign that you're most likely doing something wrong.

coldtea 10y ago
>that if you find yourself working with offsets and DST values, it's a sign that you're most likely doing something wrong. The video is wrong then. If you're writing an application that deals with times (e.g. stores and queries events with specific timestamps) and you don't take offsets and DST values into account, you get all kinds of weird edge cases.
- realharo 10y ago
  No, the point is that you should not be doing those thing manually, i.e. you should never be adding integer offsets to something or doing similar operations. Instead, all the rules for conversions between times are already stored in the timezone database, so all you should do is something like ToAbsolute(CivilTime, TimeZone) and the reverse. He also mentions (at 26:50) proper ways of dealing with repeating and non-existent civil times close to DST transitions (and sane default ways if you just don't want to bother). When talking about JSON or serialization formats specifically, none of the complexities need to ever leak into the representation.
  - masklinn 10y ago
    > Instead, all the rules for conversions between times are already stored in the timezone database, so all you should do is something like That only works if you're completely detached from the user and don't care for them. Example: On January 1st 2011, a Samoan user living in Samoa (timezone Pacific/Apia) records an event for January 1st 2012. You convert January 1st 2012 09:00:00 to UTC, storing 2011-01-01T20:00:00. On January 2nd 2012 at 10AM, you remind your user that they had an event set. Because in May 2011 Samoa announced they were going to skip a local day and move across the international date line. So 2011-12-30T09:00:00 UTC was 2011-12-29T23:00:00 Pacific/Apia, but 2011-12-30T10:00:00 UTC was 2011-12-31T00:00:00 Pacific/Apia. And as far as your user is concerned, they told you to ping them on January 1st at 9AM and you pinged a day late. Just because you store absolute datetimes doesn't mean you won't fuck up, and when the data is user-provided, chances are as good that that decision will be the one fuckup.
    - realharo 10y ago
      That still doesn't mean that you should do any of those operations by hand (which is what the previous comment was about). But sure, if you do scheduling for future times, you do need to be aware of such possibilities and store the future times as civil times (and have some sane way of handling non-existing/repeating times - but again, most of the time the system/library will do this for you). Then even if the user is flying across the world, they can still get the alert at the right time wherever they are (assuming the device updates local timezone based on location). I never said that you should only store absolute times - only that they are a separate data type and you shouldn't mix them or try to convert them by hand.
  - andrewaylett 10y ago
    +1 serialise things without the processing complexities. In general, an event is either scheduled in the future relative to a specific physical location, in which case you want to record it with a symbolic timezone reference (in case the TZ DB changes in the meantime), or it's timed absolutely, in which case you want to record it as UTC. The trick is knowing which events are which. If you're scheduling something for a machine, probably just use UTC. If you're machine-recording the time of an event, even if it's based on a human pushing a button, use UTC and convert back to local time for display if necessary. If the user told you what time they wanted to store, store it as local time with a symbolic timezone. Where it gets really difficult is interoperating with systems that don't do things properly, or working within systems that don't let you do things properly.

coldtea 10y ago

>that if you find yourself working with offsets and DST values, it's a sign that you're most likely doing something wrong. The video is wrong then. If you're writing an application that deals with times (e.g. stores and queries events with specific timestamps) and you don't take offsets and DST values into account, you get all kinds of weird edge cases.

realharo 10y ago
No, the point is that you should not be doing those thing manually, i.e. you should never be adding integer offsets to something or doing similar operations. Instead, all the rules for conversions between times are already stored in the timezone database, so all you should do is something like ToAbsolute(CivilTime, TimeZone) and the reverse. He also mentions (at 26:50) proper ways of dealing with repeating and non-existent civil times close to DST transitions (and sane default ways if you just don't want to bother). When talking about JSON or serialization formats specifically, none of the complexities need to ever leak into the representation.
- masklinn 10y ago
  > Instead, all the rules for conversions between times are already stored in the timezone database, so all you should do is something like That only works if you're completely detached from the user and don't care for them. Example: On January 1st 2011, a Samoan user living in Samoa (timezone Pacific/Apia) records an event for January 1st 2012. You convert January 1st 2012 09:00:00 to UTC, storing 2011-01-01T20:00:00. On January 2nd 2012 at 10AM, you remind your user that they had an event set. Because in May 2011 Samoa announced they were going to skip a local day and move across the international date line. So 2011-12-30T09:00:00 UTC was 2011-12-29T23:00:00 Pacific/Apia, but 2011-12-30T10:00:00 UTC was 2011-12-31T00:00:00 Pacific/Apia. And as far as your user is concerned, they told you to ping them on January 1st at 9AM and you pinged a day late. Just because you store absolute datetimes doesn't mean you won't fuck up, and when the data is user-provided, chances are as good that that decision will be the one fuckup.
  - realharo 10y ago
    That still doesn't mean that you should do any of those operations by hand (which is what the previous comment was about). But sure, if you do scheduling for future times, you do need to be aware of such possibilities and store the future times as civil times (and have some sane way of handling non-existing/repeating times - but again, most of the time the system/library will do this for you). Then even if the user is flying across the world, they can still get the alert at the right time wherever they are (assuming the device updates local timezone based on location). I never said that you should only store absolute times - only that they are a separate data type and you shouldn't mix them or try to convert them by hand.
- andrewaylett 10y ago
  +1 serialise things without the processing complexities. In general, an event is either scheduled in the future relative to a specific physical location, in which case you want to record it with a symbolic timezone reference (in case the TZ DB changes in the meantime), or it's timed absolutely, in which case you want to record it as UTC. The trick is knowing which events are which. If you're scheduling something for a machine, probably just use UTC. If you're machine-recording the time of an event, even if it's based on a human pushing a button, use UTC and convert back to local time for display if necessary. If the user told you what time they wanted to store, store it as local time with a symbolic timezone. Where it gets really difficult is interoperating with systems that don't do things properly, or working within systems that don't let you do things properly.