Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC 9557: Date and Time on the Internet: Timestamps with Additional Information

rfc-editor.org

Post reply on HN
Print view View original

21–26 of 26 posts

Re: RFC 9557: Date and Time on the Internet: Timestamps with Additional Information

#21

Post by Martinussen »

dotancohen wrote: post #19
Martinussen wrote: post #16

Earlier quoted context omitted.

> Nor does it allow setting a date on e.g. 25th of Shaaban, considering that we don't yet know on which day the 25th of Shaaban will fall on the Gregorian calendar. What's an example this would matter for? In my head, you wouldn't/couldn't store "a currently semi-arbitrary undefined time between X and Y" as a timestamp, because it isn't one, and can't be used as one. I don't think timestamps should handle Easter eith…

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.

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.

Re: RFC 9557: Date and Time on the Internet: Timestamps with Additional Information

#22

Post by happytoexplain »

Y_Y wrote: post #20
crote wrote: post #15

Earlier quoted context omitted.

> Even if a luser can roughly guess what $ts means, it's never going to make it into the UI. It's not intended to. It's designed for standardized machine-to-machine communication, which is currently a mostly unsolved problem for zoned timestamps.

I interpret RFC 3339 not to apply exclusively to machine-to-machine communication. Specifically section 5.3 includes the following: > a balance must be struck between human readability and interoperability. and > Internet clients SHOULD be prepared to transform dates into a display format suitable for the locality. (where SHOULD is used in the RFC 2119 sense equivalent to RECOMMENDED).

Human readability does not mean end user readability. It's good if humans can read it so that programmers/admins can read it, and also end users if they happen to be exposed to it. But for display to end users, it should always be formatted in a localized, naturally readable manner with no concern for machine parsing (which is what the second quote is referring to).

Re: RFC 9557: Date and Time on the Internet: Timestamps with Additional Information

#23

Post by dotancohen »

Martinussen wrote: post #21
dotancohen wrote: post #19

Earlier quoted context omitted.

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.

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…

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.

Re: RFC 9557: Date and Time on the Internet: Timestamps with Additional Information

#24

Post by Martinussen »

dotancohen wrote: post #23
Martinussen wrote: post #21

Earlier quoted context omitted.

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…

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.

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.)

Re: RFC 9557: Date and Time on the Internet: Timestamps with Additional Information

#25

Post by dotancohen »

Martinussen wrote: post #24
dotancohen wrote: post #23

Earlier quoted context omitted.

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.

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 m…

The culture is not changing. They just don't know on what specific day they will be able to observe the moon some months.

Re: RFC 9557: Date and Time on the Internet: Timestamps with Additional Information

#26

Post by Martinussen »

dotancohen wrote: post #25
Martinussen wrote: post #24

Earlier quoted context omitted.

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 m…

The culture is not changing. They just don't know on what specific day they will be able to observe the moon some months.

I meant that "Cultures and systems might change in the future" is the current/proposed state, and "All future dates beyond the current year are currently unknown" is unreasonable.
Post reply on HN