On 2 Jan 2025, at 23:33, Antero Mejr <xxxxxx@antr.me> wrote:

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

I will provide a make-moment procedure in the next version of the pre-SRFI so it will be possible to do this in a way that doesn’t ‘look wrong’ when someone does it. Also, I have added requirements that time zone objects have to be preserved by object identity through creation and deconstruction of a timestamp object.

This means in this case you could use the utc-offset-timezone procedure to implement your own custom conversion between moments and timestamps, and use the object identity of a timezone object to associate any additional information with the resulting timestamp object.

I think this solves the problem without wrong things looking wrong.

I’ve also made it explicit that how time zone database information gets found is implementation-specified. Thanks!

Daphne