Hi Antero,

On 26 Dec 2024, at 21:11, Antero Mejr <xxxxxx@antr.me> wrote:

>> <https://gitlab.com/dpk/presrfis/-/blob/master/date-time.md>
>
> Thanks for this, it looks really helpful. Is this intended to supersede
> or supplement SRFI 19? If it supersedes SRFI 19, would the interface be
> backwards-compatible to some extent?

I see it more as superseding SRFI 19.

It takes a much different approach to SRFI 19, which offers a set of abstractions which don’t seem to me to be very useful. It offers a more direct correspondence to many of the data types and operations defined in the latest edition of ISO 8601, adapted to the Scheme context (by providing an intermediate TAI-based layer), and in a way that would make using these types with the Unicode CLDR (whether directly or through something like ICU) easy.

I think you could probably write fairly simple and lightweight conversions between the SRFI 19 data types and the ones in this SRFI, at least for some of the timescales SRFI 19 supports.

> Some thoughts:
>
> Can the phrase:
> "implementations should use the time zone database provided by the
> operating system"
> be extended with something like:
> "..., and respect user-specified settings relating to such."
> That way users can (hopefully) count on implementations respecting
> things like $TZDIR, which is necessary on some systems.

I think this should be left up to the implementation. But your proposed addition is quite general, so perhaps some form of it could work.

> Also it may be worth explicitly mentioning or requiring use of the IERS
> leap seconds database, if the SRFI mentions or requires use of the Olson
> DB.

Indeed, it says the ‘right’ versions of timezones should be used, not the ‘posix’ ones. The ‘right’ versions include leap second data.

Unfortunately, since writing it I have learned that not all OSes that ship the Olson database include the ‘right’ versions, although they do supply leap-seconds.list. Arvydas, who is implementing the SRFI, tells me he has written a leap-seconds.list parser and it should be possible to use that in combination with the ‘posix’ data to get the correct result.

> For the timezones, would it make sense to provide a tai-timezone with no
> delta, then replace utc-offset-timezone with a more general
> `(timezone-offset-timezone TZ DT)` for composability? In case a user
> wants to parse leap-seconds.list and a zoneinfo file manually, like
> this:
>
> ```
> ;; Two leap seconds plus one hour.
> (define two-leap-sec (seconds-dt -2)) ;parsed from leap-seconds.list
> (define cet-plus1-zone (hours-dt 1)) ;parsed from zoneinfo
> (define offset (dt+ two-leap-sec cet-plus1-zone))
> (define my-timezone (timezone-offset-timezone
>                     tai-timezone
>                     offset))
> ```

Hmm. Maybe. Can you offer a practical reason for doing this? It seems to me at first glance to fail the ‘wrong things should look wrong’ test.

Daphne