Glibc is still not Y2038 compliant by default

Re:Glibc is still not Y2038 compliant by default by masklinn on Wednesday December 29, 2021 @07:20AM (#29724155)

> Just store the time stamp and time zone separately and update the time stamp to reflect any changes to a time zone's offset

Thus reinventing zoned datetimes badly

> if that actually happens

It happens literally all the time, sometimes with very little heads up e.g. the decision to apply DST or not can be take mere weeks before it actually occurs[0], and something as impactful as an entire calendar day disappearing can happen with 6 months notice[1].

[0] https://egyptindependent.com/egypts-hasty-goodbye-daylight-s..., https://codeofmatt.com/time-zone-chaos-inevitable-in-egypt/

[1] https://www.theguardian.com/world/2011/dec/30/samoa-loses-da...

[ Parent | on HN ]

Re:Glibc is still not Y2038 compliant by default by osrec on Wednesday December 29, 2021 @08:51AM (#29724761)

Thanks for this - I've learned something new today. I did not realise timezone updates were so frequent.

I do find that having the timestamp at hand makes math easier in a lot of the use cases I've come across. I wonder if there is an easy hybrid solution where you can capture timezone info, timestamp info and have it adjust without a full DB update, even if timezone offsets change. Maybe a mapping table of some kind, with versioned timezone codes.

[ Parent | on HN ]

Re:Glibc is still not Y2038 compliant by default by masklinn on Wednesday December 29, 2021 @08:56AM (#29724806)

Do note that this is an issue for future events.

For past events, you can store timestamps, it doesn't matter, the mapping is known and fixed.

[ Parent | on HN ]