Hexadecimal clock counting down to 2038 problem

Re:Hexadecimal clock counting down to 2038 problem by mjevans on Sunday September 17, 2023 @08:01PM (#37550654)

Dates / timestamps fail to capture an 'event'. At best they are a partial event specification with the assumption that they are converted correctly to an assumed increment along a single time scale.

Event specification is a very complex and politically entwined idea. This involves not just a frame of reference for the time, but also a location within which that time should make sense. Otherwise it is impossible to derive the correct rule-set for evaluating the human interpreted value of that moment.

An alternative which might make sense is to force people to specify which ruleset they desire with the offset value within said ruleset.

Sadly, my preferred representation of time isn't expressed in either of the popular standards (RFC 3339 or ISO-8601). https://ijmacd.github.io/rfc3339-iso8601/

RFC 3339 gets closet to my preference with: 2023-09-17 23:51:41Z

However these are examples of what I'd prefer to see:

  * 2023-09-17 23:51:41 Z UTC
  * 2023-09-17 16:51:41 PST8PDT USA/WA/Seattle
  * 2023-09-17 16:51:41 PST8PDT Canada/British Columbia/Vancouver

Note: At the moment Vancouver BC and Seattle WA happen to observe the same time offset but are in different political locales with different DST shift times. I'm not sure if it's still correct to call either timezone PST8PDT... that may imply the USA/CA/Los Angeles.

Time would be expressed numerically 'large endian first' format, with zero or one punctuation element between units, preferably expressed with individual units matching the most correct (easiest for a human to read what they expect) value at a glance. This means - (or no separation) for dates, and : (or no separation) for HMS. (Space) or _ (Underscore) are preferable for between units. The timezone 'name' follows the smallest unit of time, which is itself followed by the reference city. Implicitly events in the past were accurate at the time they were encoded, while events in the future might need re-validation and conversion if the rules have changed. Though it would be even smarter for the human important metadata (a string, probably) of recognizing the future event(s) be stored rather than a precise moment which may be incorrect.

[ Parent | on HN ]

Re:Hexadecimal clock counting down to 2038 problem by fallingknife on Sunday September 17, 2023 @08:43PM (#37550903)

Locale and time are two separate pieces of data. Why store them together? Why not unix time and locale as two separate data points, and then mapping them to a human readable value is a UI concern?

[ Parent | on HN ]

Re:Hexadecimal clock counting down to 2038 problem by mjevans on Sunday September 17, 2023 @10:11PM (#37551419)

They are not, though it may be implicit in your thoughts that E.G. UTC or TAI or some other standard is associated with a single scalar value which represents some time along that frame of reference.

However not all times are generated within such references. Most frequently (when sampling human facing outputs) times are printed within some other reference frame. As I tried to elaborate that usually relates to political realms, and there even cities may not be a sufficiently precise specification. (Offhand E.G. would timestamps from east and west Berlin while it was divided differ? I've not memorized that trivia, but it is one example of a politically divided city.)

Further, not so many decades ago timezones along the western Americas coast happened to match, but have since diverged at times during the year due to political changes in timezone observations. It is not inconceivable that actions at a state, county, city, or other zoning level (E.G. Provences for Canada) might further change the meaning of a human friendly representation of an event (time in a place).

[ Parent | on HN ]

Re:Hexadecimal clock counting down to 2038 problem by fallingknife on Sunday September 17, 2023 @11:27PM (#37551888)

That makes sense, but really we are not going to be able to guarantee full accuracy of a timestamp against future changes in timezone boundaries. I guess if you had a GPS coordinate, that could be done, but it would be a monumental task for little benefit. Which is why IMO time data should be stored in unix, because then we can at least guarantee that we have an accurate ordering of events, at least within the precision of the timestamp.

Would rather convert to unix at the time the event is recorded since we will be able to convert to the unix standard from whatever locale. If we store timestamps with a locale then we have to worry about the exact type of locale changes that you mentioned, and there is no guarantee that we will even know how to translate the locale that was stored at the time the TS was created. Sure, unix could change too (e.g. leap seconds), but I would be much more confident that time libraries will handle such changes

[ Parent | on HN ]

Re:Hexadecimal clock counting down to 2038 problem by jakobson14 on Monday September 18, 2023 @02:17PM (#37559872)

You're going to need to answer https://news.ycombinator.com/item?id=37551163 before you continue with any more of this.

Otherwise this isn't going to be a meaningful discussion.

[ Parent | on HN ]

Re:Hexadecimal clock counting down to 2038 problem by jakobson14 on Sunday September 17, 2023 @09:27PM (#37551163)

you're stretching the definition of "event" pretty far there. if you're not referring to an atomic-clock-precise instant in time, you're going to need to elaborate as to what your definition of an "event" is and explain why location/culture/politics are important.

at any rate, if you even want to have a hope of keeping track of any of that stuff, you're going to need a rigorous and atomically-precise physical standard to actually map it all to. look at the tz database. it's a set of mappings that ultimately rely on such a standard of atomic-backed time.

[ Parent | on HN ]