On Thu, 30 Sept 2021 at 10:10, Stephen Colebourne via tz <tz@iana.org> wrote:
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.
Ditto Noda Time <https://nodatime.org>, the library for .NET 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