For the 2026a release:

    Changes to past and future timestamps

    Since 2022 Moldova has observed EU transition times, that is, it has sprung forward at 03:00, not 02:00, and has fallen back at 04:00, not 03:00.  (Thanks to Heitor David Pinto.)

▲ drdexebtjl 5 hours ago | parent [-]

Interesting. I could see that as an argument also for storing it in UTC, no?

For example, if tzdata is 1 hour off, and you store your timestamps in UTC, it's immediately obvious that a local time is wrong because users will see events that just happened as having happened 1 hour ago. Update tzdata, and now everything is right.

If you store the wall time, it _looks_ right, but fails if you attempt to compare/sort it with times in different timezones. To fix it, you need to actually modify the data in your database.

	▲	dqv 4 hours ago \| parent [-]
		Only for server-supplied timestamps. Like the time clock example: sure what you're describing works if the user is just pressing a button to clock in and the server stores a UTC timestamp in response to a POST request or whatever. But it's very common to need to backfill time. So the user backfills with their own supplied timestamps, those stamps get converted to UTC, tzdata changes a few months later, and HR is now asking for an explanation as to why they were late for those backfills and how it's possible they were working an hour after the shop closed. It's never as simple as "just store it in UTC". Conversion to UTC is lossy, so I prefer to keep up with the user-supplied time where appropriate.