[tz] TZDB use cases

Jon Skeet skeet at pobox.com
Thu Sep 30 09:15:07 UTC 2021

On Thu, 30 Sept 2021 at 10:10, Stephen Colebourne via tz <tz at iana.org>

> On Thu, 30 Sept 2021 at 09:42, Jürgen Appel via tz <tz at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210930/e86a5e4f/attachment.html>

More information about the tz mailing list