Daphne Preston-Kendal <xxxxxx@nonceword.org> writes:

>> 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.

It's for programs that need to vendor (and parse) timezone and leap
second information themselves, because they can't count on having the
correct Olson DB installed on the OS, or want to reproduce a bug or
condition caused by a certain timezone or/leap-second configuration.

A practical example would be a shared calendar that needs to calculate a
synchronized meeting time for networked computers in different time
zones. Or a program that needs to use a certain timezone DB for
historical accuracy or regulatory compliance, but may be installed on a
wide variety of systems.

It would definitely fail the ‘wrong things should look wrong’ test, but
if one is using that part of the API, then it would be assumed they
would know exactly what they are doing and why.