2 ms·

Really, it's an epoch problem of sorts. If we picked an epoch date with a longer view we might have a better feeling for it as large numbers. For instance we ar

Really, it's an epoch problem of sorts. If we picked an epoch date with a longer view we might have a better feeling for it as large numbers. For instance we are roughly somewhere between Y12K and Y13K since the estimated start of the Holocene. On the other side, it might feel more scientific to pick a far future epoch date and negative numbers would be a greater reminder of time running out, such this being roughly Y-5e9 until the expected death of our sun. (To be fair to the Long Now, not that they necessarily need fairness, and I'm not a member I just read about them here on HN mostly, adding the initial insignificant zero was intentionally an easy "hack" to keep things recognizable and not get into quagmires like changing the epoch date.)

ianburrell 5y ago
There is the Holocene calendar which adds 10,000 to the year. The current year would be 12022 HE. It has advantages that gets rid of BC/year zero confusion and that all historical dates are positive numbers.
- kragen 5y ago
  To me this seems like using the Unix time convention but changing the epoch time from midnight UTC to midnight at UTC-12:00, the timezone of Baker Island: it's close enough to produce confusing ambiguity (is "2020" or "02020" intended to mean two years ago, or an estimated date when Jericho's pre-pottery Neolithic A wall fell out of use, suggesting an abandonment of the site?), and it makes it more likely that your software will have untested cases with bugs in them. In the case of the Holocene Calendar the bugs would just be a question of negative dates; in the case of UTC-12:00 it would be a nonnegative epoch time that is nevertheless in 01969 instead of 01970, which will only happen if someone adopts a more westerly timezone like UTC-13:00, pretty much guaranteeing you won't test that case beforehand. (Samoa did something similar in 02011, but it was in the other direction.) Of course, as other people have pointed out, you shouldn't use fixed-width date fields in your software.

ianburrell 5y ago

There is the Holocene calendar which adds 10,000 to the year. The current year would be 12022 HE. It has advantages that gets rid of BC/year zero confusion and that all historical dates are positive numbers.

kragen 5y ago
To me this seems like using the Unix time convention but changing the epoch time from midnight UTC to midnight at UTC-12:00, the timezone of Baker Island: it's close enough to produce confusing ambiguity (is "2020" or "02020" intended to mean two years ago, or an estimated date when Jericho's pre-pottery Neolithic A wall fell out of use, suggesting an abandonment of the site?), and it makes it more likely that your software will have untested cases with bugs in them. In the case of the Holocene Calendar the bugs would just be a question of negative dates; in the case of UTC-12:00 it would be a nonnegative epoch time that is nevertheless in 01969 instead of 01970, which will only happen if someone adopts a more westerly timezone like UTC-13:00, pretty much guaranteeing you won't test that case beforehand. (Samoa did something similar in 02011, but it was in the other direction.) Of course, as other people have pointed out, you shouldn't use fixed-width date fields in your software.