On 2026-01-24 19:48, Berthold Stoeger via subsurface wrote:
Storing it in second is probably best, as the local time field also has
seconds granularity.
IFF we do something to make this code timezone aware, we absolutely
should
not be reinventing how to do that from whole cloth. This is a very well
researched problem, with long established solutions, which we'd need to
interface with anyway, so converting to or from our own special sauce to
that is just going to add more complexity, more sources of errors, and
more corner cases that we have no way of knowing how to resolve.
For political/administrative timezone (where you know where you are, and
who determines local time, but don't know or care exactly when DST
starts
or ends or if they have it at all, and how that has changed
historically)
we have the TZ database and the zones it defines:
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
For the case where you have a timestamp that explicitly provides
timezone
or offset information, we have ISO 8601
https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
Many implementations do explicitly allow the TZ database timezone
abbreviations in place of the UTC offset (ie. PST/PDT as shorthand for
-0800/-0700 respectively), and that is an extension to the standard,
but we probably need to be prepared for devices and file metadata to
be using that extension.
Nowhere and nothing uses an offset in *seconds*, and AIUI, by convention
all extant zones are multiples of nothing less than 15 minutes.
It's not that hard to get this right - but it really is easy to get it
Horribly Wrong and paint yourself into a corner that it's very hard or
impossible to get back out of.
So *iff* we store timezone data, it should be an arbitrary string,
which can safely be "empty" in the case where no zone is specified
and we should interpret the standard well known values for it in the
standard well known ways and ignore anything that isn't valid in
that framework.
Ron
(who has been burned too often by things getting this wrong before ;)
_______________________________________________
subsurface mailing list -- [email protected]
To unsubscribe send an email to [email protected]
