4 ms·

I imagine many things use Unix time or a similarly flat calendar internally (Twitter's Snowflake[0] uses a custom scale), it's the translation into the Gregoria

I imagine many things use Unix time or a similarly flat calendar internally (Twitter's Snowflake[0] uses a custom scale), it's the translation into the Gregorian (/Jewish/Mayan/etc) calendar and time scale where the bugs come from. Can't count on 31540000 seconds being a year, time zones, etc. At the same time, the human brain doesn't seem particularly well-suited to breaking down Unix time into meaningful and reliably consistent scales, so I don't see time getting much easier barring some revolutionary timekeeping system. [0] https://github.com/twitter/snowflake https://github.com/twitter/snowflake

chimeracoder 14y ago
Off the top of my head, it's easier to think of APIs that don't provide UNIX timestamps than ones that do. You wouldn't believe some of the half-baked implementations I've seen used in production code (unless you've also had to deal with it yourself, that is!) Yes, you still have to deal with timezones, but I'd much rather be given a UNIX timestamp for a UTC time and then adjust accordingly, rather than deal with all the other problems that come from communicating and converting between various other calendar formats and locales. And this exchange should occur at the very last step, only when being displayed to the user. For almost any other purposes, there's no reason that two different applications should need to talk to each other using anything but UNIX timestamps. The potentially error-prone conversion should happen in the latest stage possible, because that's the part with the most knowledge of how any error should be corrected. > At the same time, the human brain doesn't seem particularly well-suited to breaking down Unix time into meaningful scales, But we're talking about for programming purposes - to a computer, one 64-bit int is as good as any other.
- rmc 14y ago
  There is not a 1:1 correspondence between Unix time and UTC. For example, what's the Unix time for 23:59:60 30th June 2012?
  - chimeracoder 14y ago
    > There is not a 1:1 correspondence between Unix time and UTC Or between any two time formats, but Unix time still makes for the cleanest intermediary by far.
    - rmc 14y ago
      No, it is possible to convert between some time formats. For example, if I invented a new time format that actually was "number of seconds since midnight 1/1/1970" then you could actually convert 1:1 between it and UTC. It's just that you can't do it with some formats, like UTC - Unix time or UTC - (only include the last 2 digits of the year like in Y2K)
      - chimeracoder 14y ago
        My point is that there's no one format that's going to have seamless conversion with everything that various applications need, but the UNIX timestamp still makes for the best intermediary by far.
        rmc 14y ago
        There's a difference between "This is not a great time format for conversions" and "This value in the format represents 2 possible different actual times and we have no idea how to tell them apart"
    - wl 14y ago
      UTC is cleaner than Unix time. Slewing the clock to deal with leap seconds isn't exactly clean. TAI is even better, though. A steady stream of seconds after an epoch without leap seconds causing complications.
- alayne 14y ago
  I have seen people store dates in string form, in memory, converting to and from string form as they are updated. It hurts to read code like that.
  - chimeracoder 14y ago
    Instead of telling you about the worst one I've seen in an API implementation, I might as well just show you the code it took to turn it into a correct timestamp: https://gist.github.com/4438567 https://gist.github.com/4438567 (Yes, they gave TWO separate UNIX timestamps, neither of which corresponded to the actual time of interest).
  - deleted 14y ago
    [deleted]
- bwooce 14y ago
  Well, no there are several good cases where storing a time in UTC as seconds since an epoch is wrong. It's a common mistake. The first usecase is Birthdays. For most purposes people do not want to store the extract time and date of their birthday in the original time zone. Apple do this, much to my annoyance - it means people's birthdays change as you move around our planet, and that doesn't align with how they work in the real world. If I'm born in Utah on 1/1/1980 it does not mean I celebrate my birthday on 31/12 when I'm in Australia. The second usecase is recurring meetings, particularly with global participants. The mind bending case is where you have DST in some or all of the TZs. The only remotely correct thing you can do is keep the meeting at the same wall-clock time in the TZ of the meeting owner (9am meeting stays at 9am). Most apps don't, and there is no perfect answer (consider a participant in a different TZ - the meeting changes to a possibly conflicting time). Sometimes storing the absolute time/date is correct. Other times storing the original UTC offset, as well as the time in UTC is. But most of the time, yes, store it in UTC in whatever form you prefer.

chimeracoder 14y ago

Off the top of my head, it's easier to think of APIs that don't provide UNIX timestamps than ones that do. You wouldn't believe some of the half-baked implementations I've seen used in production code (unless you've also had to deal with it yourself, that is!) Yes, you still have to deal with timezones, but I'd much rather be given a UNIX timestamp for a UTC time and then adjust accordingly, rather than deal with all the other problems that come from communicating and converting between various other calendar formats and locales. And this exchange should occur at the very last step, only when being displayed to the user. For almost any other purposes, there's no reason that two different applications should need to talk to each other using anything but UNIX timestamps. The potentially error-prone conversion should happen in the latest stage possible, because that's the part with the most knowledge of how any error should be corrected. > At the same time, the human brain doesn't seem particularly well-suited to breaking down Unix time into meaningful scales, But we're talking about for programming purposes - to a computer, one 64-bit int is as good as any other.

rmc 14y ago
There is not a 1:1 correspondence between Unix time and UTC. For example, what's the Unix time for 23:59:60 30th June 2012?
- chimeracoder 14y ago
  > There is not a 1:1 correspondence between Unix time and UTC Or between any two time formats, but Unix time still makes for the cleanest intermediary by far.
  - rmc 14y ago
    No, it is possible to convert between some time formats. For example, if I invented a new time format that actually was "number of seconds since midnight 1/1/1970" then you could actually convert 1:1 between it and UTC. It's just that you can't do it with some formats, like UTC - Unix time or UTC - (only include the last 2 digits of the year like in Y2K)
    - chimeracoder 14y ago
      My point is that there's no one format that's going to have seamless conversion with everything that various applications need, but the UNIX timestamp still makes for the best intermediary by far.
      - rmc 14y ago
        There's a difference between "This is not a great time format for conversions" and "This value in the format represents 2 possible different actual times and we have no idea how to tell them apart"
  - wl 14y ago
    UTC is cleaner than Unix time. Slewing the clock to deal with leap seconds isn't exactly clean. TAI is even better, though. A steady stream of seconds after an epoch without leap seconds causing complications.
alayne 14y ago
I have seen people store dates in string form, in memory, converting to and from string form as they are updated. It hurts to read code like that.
- chimeracoder 14y ago
  Instead of telling you about the worst one I've seen in an API implementation, I might as well just show you the code it took to turn it into a correct timestamp: https://gist.github.com/4438567 https://gist.github.com/4438567 (Yes, they gave TWO separate UNIX timestamps, neither of which corresponded to the actual time of interest).
- deleted 14y ago
  [deleted]
bwooce 14y ago
Well, no there are several good cases where storing a time in UTC as seconds since an epoch is wrong. It's a common mistake. The first usecase is Birthdays. For most purposes people do not want to store the extract time and date of their birthday in the original time zone. Apple do this, much to my annoyance - it means people's birthdays change as you move around our planet, and that doesn't align with how they work in the real world. If I'm born in Utah on 1/1/1980 it does not mean I celebrate my birthday on 31/12 when I'm in Australia. The second usecase is recurring meetings, particularly with global participants. The mind bending case is where you have DST in some or all of the TZs. The only remotely correct thing you can do is keep the meeting at the same wall-clock time in the TZ of the meeting owner (9am meeting stays at 9am). Most apps don't, and there is no perfect answer (consider a participant in a different TZ - the meeting changes to a possibly conflicting time). Sometimes storing the absolute time/date is correct. Other times storing the original UTC offset, as well as the time in UTC is. But most of the time, yes, store it in UTC in whatever form you prefer.