Re:Glibc is still not Y2038 compliant by default
by mlyle on Wednesday December 29, 2021 @02:29PM
(#29728947)
Basically, it's important to recognize what you're actually measuring/capturing and store something maximally equivalent to that. Conversions may render figuring things out later impossible or very difficult.
If you care about a past moment in time as reported by GPS or a computer clock-- use a UTC timestamp.
If you care about a future time delineated by a precise interval from now-- use a UTC timestamp.
If you care about a future time expected to be delineated in a specific time zone, use a timestamp in local time and note the zone.
If you care about a future time in a customer's time zone no matter where they may be, store the time in an unspecified local time and the customer for whom the time applies. Etc.
If you need to schedule future events it gets obviously a lot more complicated, you don't need a timestamp you need local time and you need it to be robust to future changes in timezones, DSTs, politics.