Unix time is bad and needs replacement, not UTC

Re:Unix time is bad and needs replacement, not UTC by ilyt on Wednesday November 23, 2022 @07:49AM (#33718525)

Having multiple time zone databases to sync and manage sounds like even worse idea.

ID, well, it saves a tiny bit of space but honestly I don't think it is worth it if you're already storing info about timezone as text.

If you're storing it in binary form you can convert the name to DB entry on save/display

[ Parent | on HN ]

Re:Unix time is bad and needs replacement, not UTC by PurpleRamen on Wednesday November 23, 2022 @08:01AM (#33718635)

My point is, Timezone-Names alone are not completely reliable. They only name the location, but not the political or historical situation of this location.

Take Europe/Berlin for example, the city was once divided in two parts, and is now in a country which is changing timezone twice a year. With a location, you can only communicate to use the rules valid today, not rules which were valid at some point in the past, or which are valid today, but in a different situation/context.

[ Parent | on HN ]

Re:Unix time is bad and needs replacement, not UTC by bombcar on Wednesday November 23, 2022 @08:06AM (#33718671)

And parts of Mexico used to be the same timezone as Los Angeles but then daylight savings time changed and the city you referenced has to change.

There’s no way to look at America/Los Angeles and know if that is California or Oregon, and if Oregon were to give up daylight savings time you’d have a problem.

[ Parent | on HN ]