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:
>>
>>>
>>> ISO-8601 calls this a "local time", and, of course, defines a syntax
>>> for it. An example of local time in ISO-8601 syntax is: "21:00"
>>
>> Yes, of course.  But that's a string representation of a local time.  What does one use internally to represent such a time?  A special time zone that means "where I am?"
>
> If I was implementing this, I would use three disjoint record types,
> with a common parent, for local times, UTC times, and "time-zoned"
> times. Plus the necessary functions to convert between them.

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 picked the latter because I strongly believe that dates and times in the present and past should be stored as TAI and time zone conversion (which implicitly includes applying leap seconds) should be done only at the last possible moment before displaying it to a human. I regard this as a correction of the popular, but wrong, ‘best practice’ of storing all dates and times as UTC and doing the time zone conversion only to show a time to a human.

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?

Daphne