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

11–20 of 26 posts

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

#11

Post by Y_Y »

ptsneves wrote: post #9

Can anybody explain why we should just not do what unix and gps do and use an agreed upon epoch, and let all the front ends make the conversions? I genuinely dread human readable timestamps inside backend code and always use unix time. Even in front end adding the whole human readable time stamp takes almost 60 characters out of the logs. I often look at timestamps in human format and wonder what time zone is this, a…

Because time is relative (to observers) and more importantly, time is political and gets set and changed by decree.

But actually I wonder the same thing. If I was to go looking for answers I'd start somewhere like here (list of falsehoods programmers believe about time): https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...

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

#12

Post by someothherguyy »

crote wrote: post #5

I feel like they are making a massive mistake by allowing UTC offset in the ISO8601 part of the timestamp. They try to extend the existing format in a seemingly backwards-compatible way, but ignore the fact that the existing format is fundamentally broken . A stamp like "2022-07-08T00:14:07+01:00[Europe/Paris]" should never be a thing. It's invalid. Downstream code can treat it as either "+01:00" or "Europe/Paris" (w…

> A stamp like "2022-07-08T00:14:07+01:00[Europe/Paris]" should never be a thing. It's invalid. Downstream code can treat it as either "+01:00" or "Europe/Paris" (which at that point is on +2:00), so you are begging for data corruption. The whole concept of "inconsistent timestamps" should not exist!

The spec states you would ignore the [Europe/Paris] in that case, no? Not either or?

Also, the specification states you can opt in to the behavior that you are asking for by marking it as critical?

2022-07-08T00:14:07+01:00[!Europe/Paris]

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

#13

Post by crote »

someothherguyy wrote: post #12
crote wrote: post #5

I feel like they are making a massive mistake by allowing UTC offset in the ISO8601 part of the timestamp. They try to extend the existing format in a seemingly backwards-compatible way, but ignore the fact that the existing format is fundamentally broken . A stamp like "2022-07-08T00:14:07+01:00[Europe/Paris]" should never be a thing. It's invalid. Downstream code can treat it as either "+01:00" or "Europe/Paris" (w…

> A stamp like "2022-07-08T00:14:07+01:00[Europe/Paris]" should never be a thing. It's invalid. Downstream code can treat it as either "+01:00" or "Europe/Paris" (which at that point is on +2:00), so you are begging for data corruption. The whole concept of "inconsistent timestamps" should not exist! The spec states you would ignore the [Europe/Paris] in that case, no? Not either or? Also, the specification states yo…

No, the spec states that you MAY resolve the inconsistency. For non-critical tags it would be acceptable to interpret it as either "2022-07-08T00:14:07+01:00", "2022-07-08T00:14:07[Europe/Paris]", throw an error, or ask the user for clarification.

Throwing an error is the only thing you can reasonably do because you're dealing with invalid data. Yes, there is the "critical" flag, but that's not helping much. There should not be an opt-in "don't corrupt my data" flag because there aren't any scenarios where you don't want it to be set.

Having the option with an opt-in flag should never happen. Having it with a mandatory critical flag is a bad idea, but not horrible. But if you're designing a new standard, why not just avoid the whole problem altogether by simply not introducing the whole concept of inconsistent timestamps in the first place?

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

#14

Post by crote »

ptsneves wrote: post #9

Can anybody explain why we should just not do what unix and gps do and use an agreed upon epoch, and let all the front ends make the conversions? I genuinely dread human readable timestamps inside backend code and always use unix time. Even in front end adding the whole human readable time stamp takes almost 60 characters out of the logs. I often look at timestamps in human format and wonder what time zone is this, a…

It is the 8th of December 2024. I schedule a meeting for the 1st of August 2025 at 09:00 local time.

Your calendar app looks up my timezone. I live in Europe, so at the 1st of August 2025 I'll be observing summer time, so I'll be using CEST - which is UTC+2:00. You convert it to the Unix timestamp 1733658933 and store that.

It is February 2025. The EU passes legislation to abolish summer time.

It is March 2025. Your app gets a timezone file update.

It is the 1st of August 2025. Your app retrieves the timestamp for the meeting, which occurs at 1733658933. You convert it to my local time. I live in Europe, so I'll be using CET, which is UTC+1:00. You convert it to the 1st of August 2025, 08:00 local time.

I am an hour early for my meeting. It is your app's fault. All timestamps converted from CEST are incorrect. You didn't store the original timezone, so you have no way to correct it. You get thousands of angry emails, and everyone abandons your app.

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

#15

Post by crote »

Y_Y wrote: post #10

It is somewhat ironic that the date reference in use throughout that page is of the form "April 1987”. I greatly respect the effort to make a well-thought-out timestamp that balances readability and cultural neutrality and versatility across contexts and eras. I try to use at least ISO–8601 timestamps when I can. It sometimes feels like a losing battle though. Even if a luser can roughly guess what 1996-12-19T16:39:5…

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

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

#16

Post by Martinussen »

dotancohen wrote: post #3

This is a valiant attempt at resolving an extraordinarily difficult problem, but it falls far too short. Just as an example, I am very happy to see that they address alternative calendars such as Arabic and Hebrew calendars. But they only address representing specific points in time as Gregorian dates, and then suggesting to alternate -calendar-aware applications that these specific Gregorian dates should be shown in…

> 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 either, it feels like two very different domains.

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

#17

Post by 112233 »

crote wrote: post #14
ptsneves wrote: post #9

Can anybody explain why we should just not do what unix and gps do and use an agreed upon epoch, and let all the front ends make the conversions? I genuinely dread human readable timestamps inside backend code and always use unix time. Even in front end adding the whole human readable time stamp takes almost 60 characters out of the logs. I often look at timestamps in human format and wonder what time zone is this, a…

It is the 8th of December 2024. I schedule a meeting for the 1st of August 2025 at 09:00 local time. Your calendar app looks up my timezone. I live in Europe, so at the 1st of August 2025 I'll be observing summer time, so I'll be using CEST - which is UTC+2:00. You convert it to the Unix timestamp 1733658933 and store that. It is February 2025. The EU passes legislation to abolish summer time. It is March 2025. Your…

Or, even simpler, you ask for monthly total, and backend has no idea what "monthly" means, because it started/ended at undetermined local hour that has been discarded when converting to "utc"

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

#18

Post by happytoexplain »

crote wrote: post #14
ptsneves wrote: post #9

Can anybody explain why we should just not do what unix and gps do and use an agreed upon epoch, and let all the front ends make the conversions? I genuinely dread human readable timestamps inside backend code and always use unix time. Even in front end adding the whole human readable time stamp takes almost 60 characters out of the logs. I often look at timestamps in human format and wonder what time zone is this, a…

It is the 8th of December 2024. I schedule a meeting for the 1st of August 2025 at 09:00 local time. Your calendar app looks up my timezone. I live in Europe, so at the 1st of August 2025 I'll be observing summer time, so I'll be using CEST - which is UTC+2:00. You convert it to the Unix timestamp 1733658933 and store that. It is February 2025. The EU passes legislation to abolish summer time. It is March 2025. Your…

As far as I can tell, the parent is asking the even simpler version of this question, which is "why not just store everything as a Unix timestamp", so even just the obvious example suffices:

I set a 9:00am alarm and then move to a new time zone.

If they meant "why not store everything as a Unix timestamp after pencil-erasing the time zone and replacing it with +0000", then you'd need the more complex example, but then the reference to GPS wouldn't make sense.

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

#19

Post by dotancohen »

Martinussen wrote: post #16
dotancohen wrote: post #3

This is a valiant attempt at resolving an extraordinarily difficult problem, but it falls far too short. Just as an example, I am very happy to see that they address alternative calendars such as Arabic and Hebrew calendars. But they only address representing specific points in time as Gregorian dates, and then suggesting to alternate -calendar-aware applications that these specific Gregorian dates should be shown in…

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

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

#20

Post by Y_Y »

crote wrote: post #15
Y_Y wrote: post #10

It is somewhat ironic that the date reference in use throughout that page is of the form "April 1987”. I greatly respect the effort to make a well-thought-out timestamp that balances readability and cultural neutrality and versatility across contexts and eras. I try to use at least ISO–8601 timestamps when I can. It sometimes feels like a losing battle though. Even if a luser can roughly guess what 1996-12-19T16:39:5…

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

Post reply on HN