undefined | Better HN

0 pointsdotancohen1y ago0 comments

This would matter for literally anything that you would schedule time for - meetings, doctor appointments, school activities, etc. Not all people use the Gregorian calendar in their daily lives.

The time of the meeting is not arbitrary - it just corresponds to a date in a different calendar. Some calendars, e.g. the calendar used in Saudi Arabia, depend on observation of the new moon.

0 comments

Martinussen1y ago

Before that observation (and importing that event into your application!), is it not semi-arbitrary, as far as the code is concerned? A fully defined point in the future (currently) corresponds 1:1 to a unix time, or a timestamp from this RFC, almost by definition.

If you can't calculate a delta from $now, or "are $X and $Y the same moment in time" , I don't think "timestamps" are the tool. Seems beyond the scope of RFCs like this, at least to me.

Without guaranteed internet access, how would you set an alarm for "this day next year"? Timezones changing already cause problems there, but those were least correct at one point - not a "quantum timestamp" of sorts.

dotancohenOP1y ago

You have the same problem in Gregorian calendar, no?

How many leap seconds will occur between now and when Europa Clipper intercepts Jupiter? That's actually important to know, e.g. for scheduling radio telescope time.

And let's not forget that some Pacific island nations have actually skipped entire days to just to another side of the date line.

Martinussen1y ago

That's what the end of my last comment was trying to touch on - timestamps are always imperfect for certain edge cases, but I would say that scheduling radio telescope time probably doesn't meaningfully benefit from trying to latch itself on to this RFC either, in that case?

The problem of "All future dates beyond the current year are currently unknown" is unsolvable in a very different way to "cultures and systems might change in the future".

(Though, wouldn't you be fine in your example? "X time after TS" wouldn't change, right? If you need atomic time anyways.)

1 more reply

j / k navigate · click thread line to collapse

0 comments

Martinussen1y ago

If you can't calculate a delta from $now, or "are $X and $Y the same moment in time" , I don't think "timestamps" are the tool. Seems beyond the scope of RFCs like this, at least to me.

dotancohenOP1y ago

You have the same problem in Gregorian calendar, no?

How many leap seconds will occur between now and when Europa Clipper intercepts Jupiter? That's actually important to know, e.g. for scheduling radio telescope time.

And let's not forget that some Pacific island nations have actually skipped entire days to just to another side of the date line.

Martinussen1y ago

The problem of "All future dates beyond the current year are currently unknown" is unsolvable in a very different way to "cultures and systems might change in the future".

(Though, wouldn't you be fine in your example? "X time after TS" wouldn't change, right? If you need atomic time anyways.)

1 more reply

j / k navigate · click thread line to collapse