On Sun, Nov 10, 2024 at 11:12 AM Daphne Preston-Kendal
<xxxxxx@nonceword.org> wrote:
> On 10 Nov 2024, at 06:06, Pierpaolo Bernardi <xxxxxx@gmail.com> wrote:
> > On Sun, Nov 10, 2024 at 5:29 AM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
> >> On Sat, Nov 9, 2024 at 4:56 PM Pierpaolo Bernardi <xxxxxx@gmail.com> wrote:

> An earlier version of this pre-SRFI (before it was going to be a SRFI, in fact, and was just my own private date and time library) did have ‘UTC moments’ as a different type from ‘TAI moments’, and then you would implement time zone conversions on top of the UTC moments.
>
> I decided it was simpler and probably more correct to handle the TAI to UTC conversion in the same layer as the time zone representation. The Olson time zone database packages them up together under the very helpful name ‘right’.
>
> The ‘more correct’ part was admittedly more of a gut feeling. The notion of a ‘UTC moment’ seemed quite useless because it was nothing more than a single-field record type wrapping a TAI moment, suggesting to me that either the UTC conversion functionality should be available as simple procedures on a TAI moment, or that UTC conversion should be handled at the same level as time zone conversion.

I have to quibble about terminology:

- TAI is a specialistic time scale. It's not just UTC ignoring leap seconds.

- The conversion between TAI and UTC is not trivial (see reference
SOFA), and of course it has a meaning only for times after the two
time scales were established.

- Conceptually, unless you are a metrology laboratory with your own
atomic clocks participating in the definition of TAI, you don't have
access to any form of current TAI. UTC is what is distributed for
civil use. The correlation between TAI and UTC is established only
retroactively (see reference TFAC).

- IMHO, for the standard library of a programming language it is too
much to require users to understand the subtle differences between TAI
and UTC. Usually, these are things we want to know as little as
possible. Unless one is an astronomer, in which case they will use a
specialistic external library (see reference SOFA)

So, if one just wants a time scale useful for everyday tasks which
avoids the nuisance of leap seconds, it would be better to simply use
the number of SI seconds since an epoch. Or alternatively we could do
what astronomers do and use the "day" as basic unit of time (SOFA,
again...).

> Can you explain why you think UTC times should be a different type to local times/time zoned times? What is the difference between a local time and a time-zoned time in your proposal?

The only difference would be how they are printed (suffix "Z" vs. "+00").
The why, would be to be as close as possible to ISO-8601, but I agree
that having different types is not an essential point.

====
* SOFA is http://www.iausofa.org/
Especially relevant for this topic is: http://www.iausofa.org/sofa_ts_c.pdf

I have a port to scheme of the time-related parts of SOFA. I will
publish it later today or tomorrow. I do not advocate to adopt this
port for anything, but it can be useful for checking the correctness
of conversions.

* TFAC is https://www.amazon.it/Measurement-Time-Frequency-Atomic-Clock/dp/0521003970
Unfortunately it looks like it's not available anymore at a reasonable
 price. If you can borrow it from a library, I'd recommend to look at
it.