[tz] Proposal: validation text file with releases

[Bradley White]

On Wed, Jul 15, 2015 at 2:06 AM, Stephen Colebourne <scolebourne at joda.org>
wrote:

> On 15 July 2015 at 06:09, Paul Eggert <eggert at cs.ucla.edu> wrote:
> > Although it is an issue, the DST-vs-STD offsets are implementation
> details
> > that are neither exposed by the reference API nor exported to zic's
> output
> > files. Any values they internally have were not intended to be visible
> when
> > the tzdata entries were written.
>
> I think what Jon is asking, and I'm confirming, is that this data
> *should* be considered part of the public data exposed by the tzdb
> project.


Then I'll confirm Paul's point: subdividing the offset should not be
considered for part of a user API.  Indeed, if we could change history, we
should get rid of tm_isdst too.

The only place a UTC offset should be meaningful is when converting an
absolute timestamp to/from a civil YMDHMS+O, and that should only happen
within the date/time library.  Why distinguish between
{YMDHMS,stdoff=Xh,dstoff=1h,is_dst=true} and
{YMDHMS,stdoff=X+1h,dstoff=0,is_dst=*}?  They are the same time.

There may be some library with a rich TimeZone concept that exposes much of
the information found in the the tz files (and they are welcome to try to
extract it), but I would claim that such information fills a much needed
gap in a core date/time API.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20150715/6bee474d/attachment.html>