[tz] Looking for details on timezones “right/…”

Robert Elz kre at munnari.OZ.AU
Thu Jan 19 17:36:51 UTC 2023


    Date:        Thu, 19 Jan 2023 15:17:09 +0000
    From:        =?utf-8?B?SsO8cmdlbiBBcHBlbA==?= via tz <tz at iana.org>
    Message-ID:  <5648489.DvuYhMxLoT at dfm-3333-jap>

  | Or in other words: In the 'right' format, all seconds on your computer are 
  | actually SI seconds of correct and identical duration

That's correct, if you have a system which counts true UTC time.
That's not anything POSIX defined.

  | and timestamps are strictly monotonic.

That's no more or less true for UTC or POSIX time.   When running
normally each is monotonic, but in either form, the clock can always
be set backwards, making timestamps non-monotonic.

[It isn't worth wasting time here going into whether or not it makes
sense to ever just call time (or anything else) "monotonic" as such,
it is clear what the intended meaning is - but because of that the
difference between monotonic and strictly monotonic is completely
meaningless in this context.   But in most systems, timestamps are
not in any sense strictly monotonic, it is usually possible for
two events to occur close enough together that the representation
used to mark the timestamp cannot distinguish the two, and so
the two timestamps appear identical, even though one occurred after
the other - there are some systems which prevent that by arbitrarily
altering one, so that it represents a different value, but on those
systems accuracy is sacrificed to make that happen for no particularly
good reason in most cases.]

  | All the leap seconds and their issues are pushed towards 
  | the functions that convert POSIX-time to displayed local time

That, as stated, makes no sense.   If you have POSIX-time there are
no leap seconds, or their issues, to deal with, they simply do not
exist.   In all cases, converting timestamps into something that can
be displayed as local time is "pushed towards the functions...", the
kernel just counts seconds (of one type or another) and everything
else is handled by a library function (which is where the timezone
files, including the right/* ones when they're available and being
used) are used.

  | (same like 
  | daylight savings time, where time jumps of hours cause no problems).

The way that POSIX systems deal with leap seconds varies, in some there's
a "second" which by most normal measures lasts for 2 seconds (the clock sits
at xx:59:59 or xx:00:00 (where xx depends upon your timezone, and the first
59 or 00 will be different for zones not an even number of hours from UTC)
for longer than it otherwise would.   In other systems, there might be 1000
(or some other arbitrary number) of seconds before, after, or surrounding
midnight UTC which are each 1/1000 (1ms) (in that case) longer or shorter
than "normal" seconds.  Other variations are possible.

And I wouldn't ever say that any time variations or discontinuities cause
no problems - whether they have a noticeable effect or not entirely
depends upon what you're trying to do with the time, and how you're
doing it.   That applies to all of them (but the circumstances differ.)

  | In a system with 'right/*' zones, you can calculate the time difference 
  | between two time instances simply by subtracting their time stamps,
  | whereas in 'normal' systems you would have to account for leap seconds

Again, nothing related to calculating with times is ever that simple.
Certainly if all seconds are of precisely equal length, then it is
easier to calculate accurate (relatively short) durations, than it is
if the length of a second is varying slightly.

On the other hand, if you want to calculate the durations on the scale
of days or months (where noon Jan 5 is exactly 10 days after noon Dec 26
of the previous year) then if a leap second occurred at the end of Dec 31,
simply subtracting the timestamps, and converting to days/hours/... would
tell you the difference is 10 days and a second - one would need to account
for leap seconds if you're using fixed length seconds which include leap
seconds to match up times.

Nothing about calculating times is ever nearly as easy as it seems, nor
is any system for doing so obviously right, and all others obviously wrong,
unless you only have one specific application (or perhaps type of application)
in mind.  If there were, we'd all be using that system, and there would be
no variations of debate at all.  Time seems simple - it is usually the first
thing we learn how to measure as children (so it must be easy, right?)
It isn't, time is the most complex and hard to deal with measurement
system of any that exist.

  | In other words, the 'right/*' zones are useful, if you need time stamps
  | with one second accuracy or better.

Sorry, but stated as blatantly as that, that's nonsense.   Everything is
far more complex than such a simple statement can possibly account for.

  | If you can tolerate up to a few dozens seconds inaccuracy

That's nonsense too, unless you're attempting (for some bizarre reason)
to calculate second counts over periods of (currently) about 50 years.
There are a few applications where that kind of thing is needed, but it
is very rare.

  | [...] the 'normal' zones are fine.

Since most of us (here anyway) are using POSIX based systems (or similar)
and have been doing that for a long time now, and almost everything works
just like we'd expect it to (and if the timestamp on something that occurred
close to a leap second is slightly less accurate than it could be, we mostly
don't care, as it affects almost nothing), I'd suggest that the normal zones
are fine, for almost everyone, regardless of any other constraints.

Not everyone, that's true - but if you really need the right/* timezones,
then you wouldn't be asking about them in these messages.   That is, if
someone is here asking what those right/* timezones are for, then the best,
simplest, answer, is almost certainly "just ignore them".   The people who
are doing things which really need more precise long term, tend to know
what they need, and if were to ask any question here it would be "How do
I set things up so ...?" rather than "what are these for?"

kre





More information about the tz mailing list