Recreating the US/* time zone situation

Re:Recreating the US/* time zone situation by Terr_ on Sunday September 14, 2025 @12:01AM (#45237340)

It's a similar painful insanity as: "Other currencies? Just convert them to US dollars on save, and store that number in the database, nice and easy, no problems."

[ Parent | on HN ]

Re:Recreating the US/* time zone situation by s20n on Sunday September 14, 2025 @06:31AM (#45238829)

This is a false analogy. Currencies are volatile whereas timezones are static and rule based.

Converting timestamps between time zones is perfectly reversible while there is a loss of information when you convert a value to a new currency.

[ Parent | on HN ]

Re:Recreating the US/* time zone situation by WillDaSilva on Sunday September 14, 2025 @08:14AM (#45239244)

Timezones are not static, and actually change somewhat frequently. A program that converts any given future time to UTC risks becoming incorrect about when that time is due to political changes that affect the timezone the given future time was in.

[ Parent | on HN ]

Re:Recreating the US/* time zone situation by macintux on Sunday September 14, 2025 @08:00AM (#45239179)

Timezones were not historically static, and even today can change with little warning.

In U.S. states along the timezone boundaries, you’ll find situations where in the mid-20th century the timezone map of the state looks like a pepperoni pizza, and changed frequently. Reversibility is definitely not guaranteed.

[ Parent | on HN ]

Re:Recreating the US/* time zone situation by dqv on Sunday September 14, 2025 @10:23AM (#45239933)

> Converting timestamps between time zones is perfectly reversible while there is a loss of information when you convert a value to a new currency.

False. This scenario absolutely does happen:

    2027-03-08 11:00AM (Local) -> 2027-03-08 2:00PM (UTC)

    (tzdata version changes)

    2027-03-08 10:00AM (Local) <- 2027-03-08 2:00PM (UTC)

[ Parent | on HN ]