4 ms·

I have a hard time (ow) having much anger over time-related bugs these days. Seems the only real way of getting the calendar more programmer-friendly is to swit

I have a hard time (ow) having much anger over time-related bugs these days. Seems the only real way of getting the calendar more programmer-friendly is to switch the world over to Unix time.

chimeracoder 14y ago
I'm amazed by how many applications don't do this (and, similarly, how many languages make it difficult just to get a simple UNIX timestamp). It's far and away the easiest medium to work with, even if you only use it as a pivot format[1]. [1] http://en.wikipedia.org/wiki/Pivot_language http://en.wikipedia.org/wiki/Pivot_language
- ConstantineXVI 14y ago
  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.
rmc 14y ago
But then we need to do something special for leap seconds. Despite what lots of people think, Unix time is not the number of seconds since 1st Jan 1970, since it doesn't include the 30ish leap seconds that have been added since then.
- seiji 14y ago
  Quite true. Leap seconds cause an epoch repeat. Most minutes have 60 seconds (0-59), but leap seconds make a 61st second in a minute (0-60).
- ColinDabritz 14y ago
  To be clear: It's not the "correct" wall clock time for most people's day to day use, because it only counts seconds that have elapsed since 1st Jan 1970 00:00 (in a continuous unbroken manner), and does not count leap seconds (which are added to keep our daily-use times in sync with the rotation of the earth.) Isn't time fun?
- aidenn0 14y ago
  Since leap seconds are scheduled relatively close to the time that they happen, that's the only way to allow representing future times.
masklinn 14y ago
> Seems the only real way of getting the calendar more programmer-friendly is to switch the world over to Unix time. As others have noted, it'll break during leap seconds where a full second repeats and unix time "conveniently" forgets about it ever existing.

I have a hard time (ow) having much anger over time-related bugs these days. Seems the only real way of getting the calendar more programmer-friendly is to switch the world over to Unix time.

chimeracoder 14y ago

I'm amazed by how many applications don't do this (and, similarly, how many languages make it difficult just to get a simple UNIX timestamp). It's far and away the easiest medium to work with, even if you only use it as a pivot format[1]. [1] http://en.wikipedia.org/wiki/Pivot_language http://en.wikipedia.org/wiki/Pivot_language

ConstantineXVI 14y ago
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.

rmc 14y ago

But then we need to do something special for leap seconds. Despite what lots of people think, Unix time is not the number of seconds since 1st Jan 1970, since it doesn't include the 30ish leap seconds that have been added since then.

seiji 14y ago
Quite true. Leap seconds cause an epoch repeat. Most minutes have 60 seconds (0-59), but leap seconds make a 61st second in a minute (0-60).
ColinDabritz 14y ago
To be clear: It's not the "correct" wall clock time for most people's day to day use, because it only counts seconds that have elapsed since 1st Jan 1970 00:00 (in a continuous unbroken manner), and does not count leap seconds (which are added to keep our daily-use times in sync with the rotation of the earth.) Isn't time fun?
aidenn0 14y ago
Since leap seconds are scheduled relatively close to the time that they happen, that's the only way to allow representing future times.

masklinn 14y ago

> Seems the only real way of getting the calendar more programmer-friendly is to switch the world over to Unix time. As others have noted, it'll break during leap seconds where a full second repeats and unix time "conveniently" forgets about it ever existing.