<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 15, 2015 at 2:06 AM, Stephen Colebourne <span dir="ltr"><<a href="mailto:scolebourne@joda.org" target="_blank">scolebourne@joda.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15 July 2015 at 06:09, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br>> Although it is an issue, the DST-vs-STD offsets are implementation details<br>
> that are neither exposed by the reference API nor exported to zic's output<br>
> files. Any values they internally have were not intended to be visible when<br>
> the tzdata entries were written.<br>
<br>
</span>I think what Jon is asking, and I'm confirming, is that this data<br>
*should* be considered part of the public data exposed by the tzdb<br>
project.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>