News for hackers. Stuff that matters.
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?
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).

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

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.