On Thu, 30 Sept 2021 at 09:42, Jürgen Appel via tz <tz@iana.org> wrote:
> a) Although possibly a boundary case, I'd like to add that when using location
> based identifiers, for past or future times, a unique conversion from local
> time to UTC is sometimes impossible:
>
> 2020-10-25 02:30:00 Europe/Copenhagen cannot be mapped unambiguously to UTC,
> whereas the reverse mapping works of course. I am not aware of any software
> that takes this into account.
FYI, java.time.* and Joda-Time provide explicit tools for developers
to manage gaps and overlaps on the local timeline.
The .NET standard library provides tools to check for gaps and overlaps, but isn't quite as insistent on the user being aware of the possibility as Noda Time is.
> Therefore a reasonable requirement from the downstream user side would be to
> convey information about such conditions ('invalid time' , 'ambiguous time',
> evtl. also 'unconfirmed tzdata' for times not covered in the database)
>From my perspective as a software library author, handling of these
two use cases belong at the downstream library/consumer level, not at
the TZDB level.
Indeed - the required data for invalid/ambiguous time is already available in the database; it just needs to be presented appropriately. The "unconfirmed tzdata" is slightly trickier, and I'm not sure what most libraries do about that.
Jon