4 ms·

Timestamps are so complicated once you factor in timezones and daylight savings that it doesn't belong in JSON. Time zones are not static. They can change from

Timestamps are so complicated once you factor in timezones and daylight savings that it doesn't belong in JSON. Time zones are not static. They can change from country to country, or even states within countries. Ditto for when daylight savings is enacted during the year - even changing over the years. There is no rhyme or reason to any of this. The data for this has to be stored in tables and time zone meanings can change retroactively. The only reliable time stamp is UTC without leap seconds. (Speaking of leap seconds, who thought seconds going from 0 - 60 rather than 0 - 59 was a good idea?) Accurate time is one of the most difficult things to model in computer science.

realharo 10y ago
Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value. This talk explains it VERY nicely: https://www.youtube.com/watch?v=2rnIHsqABfM https://www.youtube.com/watch?v=2rnIHsqABfM Basically just decide whether you're trying to store an absolute time (a timestamp will do) or a civil time (year, month, day, etc.) and treat them as two separate data types. (If you just use "civil time + offset from UTC" like RFC 3339 does, then you can convert it to an absolute time, but you can convert only that one specific value using that offset, and not any other - i.e. that offset is not a substitute for an actual timezone identifier.)
- coldtea 10y ago
  >Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value. Not even close. http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html http://www.creativedeletion.com/2015/01/28/falsehoods-progra...
  - realharo 10y ago
    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.
- espadrine 10y ago
  If by timestamp you mean Unix time, you have to keep in mind that it evolves non-linearly. When a leap second happens, Unix time increases linearly by one second for that second, and jumps back one second, and again increases linearly by one second for the leap second. If you have sub-second precision and expect Unix time seconds to always go forward, or if you expect every Unix second to last a second (eg. by computing Unix time differences), things might break. https://en.wikipedia.org/wiki/Unix_time#Leap_seconds https://en.wikipedia.org/wiki/Unix_time#Leap_seconds
thaumasiotes 10y ago
> (Speaking of leap seconds, who thought seconds going from 0 - 60 rather than 0 - 59 was a good idea?) Who thought February going from 1-29 instead of 1-28 was a good idea? I don't understand why everyone seems to believe that the phenomena are so inherently different.
- pwfisher 10y ago
  Because other months went to 30 or 31 already, so there was room for it in calendars and people never assumed months are always the same length. 60 seconds in a minute, OTOH, is a very strong assumption in many systems and people's minds.
  - thaumasiotes 10y ago
    > other months went to 30 or 31 already, so there was room for it in calendars and people never assumed months are always the same length I really don't think this has much to do with it. It would predict no problems trying to add a November 31 to some year; I tend to make the opposite prediction.
    - sla29970 10y ago
      Remember February 30 1712? https://en.wikipedia.org/wiki/February_30#Swedish_calendar https://en.wikipedia.org/wiki/February_30#Swedish_calendar
espadrine 10y ago
> The only reliable time stamp is UTC without leap seconds. That doesn't make a lot of sense, as UTC does have leap seconds. It is similar to saying that the fastest car has no wheels, when you really mean that the fastest vehicle is a rocket. TAI is the most reliable and easiest to work with. It relies on atomic clock seconds at sea level. https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time However, it already has a difference of roughly 40 seconds with UTC (and therefore civil time), and dropping leap seconds in civil time will shift midnight to later in the day. But as the frequency of leap seconds rapidly increases, maintaining UTC will become harder. They will consider dropping leap seconds from UTC in 2023. It is unlikely that people care about having the sun rise at midnight in 30000 years.
- thymelord 10y ago
  > That doesn't make a lot of sense, as UTC does have leap seconds. Pedantic much? Posting in technical forums is such a bother. People pick at any unimportant detail. Reworded just for you: The only reliable time stamp would be something like UTC but without leap seconds.
  - espadrine 10y ago
    I am sorry. My intention was not to sound pedantic. I only wanted to point out that we are fortunate enough to already have what you describe. I too wish we used TAI-based timestamps instead of Unix timestamps in a more widespread manner! It is a bit silly that we cannot determine any duration involving a UTC time a couple of years in the future…

realharo 10y ago

Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value. This talk explains it VERY nicely: https://www.youtube.com/watch?v=2rnIHsqABfM https://www.youtube.com/watch?v=2rnIHsqABfM Basically just decide whether you're trying to store an absolute time (a timestamp will do) or a civil time (year, month, day, etc.) and treat them as two separate data types. (If you just use "civil time + offset from UTC" like RFC 3339 does, then you can convert it to an absolute time, but you can convert only that one specific value using that offset, and not any other - i.e. that offset is not a substitute for an actual timezone identifier.)

coldtea 10y ago
>Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value. Not even close. http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html http://www.creativedeletion.com/2015/01/28/falsehoods-progra...
- realharo 10y ago
  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.
espadrine 10y ago
If by timestamp you mean Unix time, you have to keep in mind that it evolves non-linearly. When a leap second happens, Unix time increases linearly by one second for that second, and jumps back one second, and again increases linearly by one second for the leap second. If you have sub-second precision and expect Unix time seconds to always go forward, or if you expect every Unix second to last a second (eg. by computing Unix time differences), things might break. https://en.wikipedia.org/wiki/Unix_time#Leap_seconds https://en.wikipedia.org/wiki/Unix_time#Leap_seconds

thaumasiotes 10y ago

> (Speaking of leap seconds, who thought seconds going from 0 - 60 rather than 0 - 59 was a good idea?) Who thought February going from 1-29 instead of 1-28 was a good idea? I don't understand why everyone seems to believe that the phenomena are so inherently different.

pwfisher 10y ago
Because other months went to 30 or 31 already, so there was room for it in calendars and people never assumed months are always the same length. 60 seconds in a minute, OTOH, is a very strong assumption in many systems and people's minds.
- thaumasiotes 10y ago
  > other months went to 30 or 31 already, so there was room for it in calendars and people never assumed months are always the same length I really don't think this has much to do with it. It would predict no problems trying to add a November 31 to some year; I tend to make the opposite prediction.
  - sla29970 10y ago
    Remember February 30 1712? https://en.wikipedia.org/wiki/February_30#Swedish_calendar https://en.wikipedia.org/wiki/February_30#Swedish_calendar

espadrine 10y ago

> The only reliable time stamp is UTC without leap seconds. That doesn't make a lot of sense, as UTC does have leap seconds. It is similar to saying that the fastest car has no wheels, when you really mean that the fastest vehicle is a rocket. TAI is the most reliable and easiest to work with. It relies on atomic clock seconds at sea level. https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time However, it already has a difference of roughly 40 seconds with UTC (and therefore civil time), and dropping leap seconds in civil time will shift midnight to later in the day. But as the frequency of leap seconds rapidly increases, maintaining UTC will become harder. They will consider dropping leap seconds from UTC in 2023. It is unlikely that people care about having the sun rise at midnight in 30000 years.

thymelord 10y ago
> That doesn't make a lot of sense, as UTC does have leap seconds. Pedantic much? Posting in technical forums is such a bother. People pick at any unimportant detail. Reworded just for you: The only reliable time stamp would be something like UTC but without leap seconds.
- espadrine 10y ago
  I am sorry. My intention was not to sound pedantic. I only wanted to point out that we are fortunate enough to already have what you describe. I too wish we used TAI-based timestamps instead of Unix timestamps in a more widespread manner! It is a bit silly that we cannot determine any duration involving a UTC time a couple of years in the future…