[tz] TZDB use cases
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
> > based identifiers, for past or future times, a unique conversion from
> > time to UTC is sometimes impossible:
> > 2020-10-25 02:30:00 Europe/Copenhagen cannot be mapped unambiguously to
> > whereas the reverse mapping works of course. I am not aware of any
> > 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
> > 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...
More information about the tz