Hacker News Reader

Hacker News

Comment by schot | Hacker News Reader

Full thread

schot

"Why is day of the month 1-indexed but the month is 0-indexed in C?"

This Twitter thread from November 2020[1] and its HackerNews discussion[2] seem relevant.

1: https://twitter.com/hillelogram/status/1329228419628998665

2: https://news.ycombinator.com/item?id=25195287

View on HN

Why don't we enumerate days throughout the year?

Because we don't.

Which is probably because it's too fine a granularity, especially historically: even an ordinal month-day had limited use to preindustrial contexts were time-boundaries were necessary quite fuzzy owing to the vagaries of communications or transport.

Technically you don't need years either, but chunky boundaries are useful as both reference points and communication shortcuts.

Probably because most calendars started as lunar or lunar-based. There is also the case that separating the year by month could be beneficial for farmers back in the day to plan different activities throughout the year. I've always like the names of the months in the French Republican Calendar[1] because of that.

[1]: https://en.wikipedia.org/wiki/French_Republican_calendar#Mon...

Excellent historical exploration of the topic => https://youtu.be/iBRCL090PxA

We enumerate milliseconds since 1 Jan 1970 12am UTC instead. You can convert to all the other formats.

Well, given a database of leap seconds you can. And you can't convent times in the future between unix time and calendar time.

Times in the future are always unreliable, even using the "normal" system there aren't any guarantees that specific time will even exist or if it does you still need to think about "is it an absolute event or a relative event and does it need to have the time updated as a result" just the other way around.

Sure. But the important difference is: I can express the time "2nd of March 2056, 15:00 UTC", we can talk about that future time, and we can tell whether we're before or after that time. But I can't express the same time in unix time, because I don't know how many leap seconds will be between now and March 2056.

Sure you can, just allow for sticking the things you want to track against at the end like you did after saying "2nd of March 2056, 15:00". If that's leap seconds then there is no reason you can't say "<future timestamp> with leap second changes" just the same as you did there with a datetime. What you can do with a timestamp is a superset of what you can do with a datetime since you start with fewer limitations but lose none of the ability to apply or mark needed transformations to that base:

Guarantees about <future date> UTC:

- Can calculate duration from past to <future date>: No (need future leap second table)

- Can calculate duration from now to <future date>: No (need future leap second table)

- Can calculate duration from future to <future date>: No (need future leap second table)

- Can compare <future date> to <future date>: No (UTC is not monotonic)

- Can know if <future date> is unique: No (UTC is not monotonic)

- Can determine <future date> has passed: After passing

- Can determine <future date> will occur: After passing (time skip adjustments and whole date skips allowed in calendar)

Guarantees about <future date> timestamp:

- Can calculate duration from past to <future date>: Yes

- Can calculate duration from now to <future date>: Yes

- Can calculate duration from future to <future date>: Yes

- Can compare <future date> to <future date>: Yes

- Can know if <future date> is unique: Yes

- Can determine <future date> has passed: Yes

- Can determine <future date> will occur: Yes

Once you add "accounting for leap seconds" to the timestamp all but "Can determine <future date> will occur" will match up. UTC didn't gain anything over timestamps in that case the difference between the two just shrunk.

While you may be able to say "I know what the UTC encoding will look like ahead of time if I specify it in UTC encoding" that doesn't actually give you any more information about the time as you can't do anything functional with that knowledge until the time passes at which point, provided the same info you had to accurately track the UTC time, you have enough information to do the same with a timestamp.

you can if you want: new Date(2022, 0, 236) is the same as new Date(2022, 7, 24)

Reply on news.ycombinator.com