[tz] Java & Rearguard

[Brandon Smith]

*Clive Wrote:*

*>> What makes you think they are? If I had tried to cite either of
thoseduring my latest degree course, I'd have been penalized
significantly. *

Regarding timeanddate.com of those specifically, I thought that was founded
by Steffen Thorsen who I thought was a contributor and resource to this
database via past announcements.




*Clive Wrote:>> But it *is* following the definition of "daylight time".
It's just thatthat doesn't match what you thought it was.*

So what is the correct definition of DST or is there one?  If I review the
sources linked from the IANA website itself [1], I again see the idea that
DST is the process of advancing clocks forward [2] (page #2 and
following).  Again, referencing timeanddate.com for Ireland [3] it shows
a +1 hour (DST Start) in the Summer (i.e. GMT->IST) and -1 hour (DST End)
in the winter (i.e. IST->GMT).  This seems to align with the idea that DST
on is the period in which clocks were advanced forward.  I thought part of
the broader issue and discussion here was that the tm_isdst flag is now
true in winter for Ireland indicating they observe DST on in the winter and
not the summer per this prior tz thread [4].  That was a lengthy discussion
and I admit I only recently started following these announcements to try
and digest all this information, so if there was a conclusion to that I
missed please do correct me.

Perhaps I've deviated from this thread's primary point here.  Our specific
issue is not with the parsing itself as we can certainly parse the data.
Our initial known issue is with the behavioral implications to our
applications that came when inverting the tm_isdst flag for Ireland.  This
change seems to contradict the definition of DST that we have thought to be
true and as far as I can tell is the definition supported everywhere
outside of this discussion.  An example of such an issue is the fact that
we now have a situation in which the transition from DST off to DST on
results in an ambiguous local time period for Ireland.  Based on the above
definitions and understanding of what is DST, this has led to an
understanding that the ambiguous period is therefore always the transition
from DST on to DST off.  Before the implementation of negative DST offsets,
this was true for Ireland.  After the introduction of negative DST offsets,
this is no longer true. I imagine there are other implications to our
applications, I haven't yet got a grasp on what those are.  My sense from
this and other threads was that we aren't alone in this problem and it
seems to me to go hand and hand with the 'Standard' discussion.

To be clear, I'm not claiming to be an expert on any of this by any means
here.  I fully recognize there are things we as a company are doing wrong.
I'm merely trying to grasp and understand if this is one of them and
admittedly having a hard time given the conflicting viewpoints in here and
information found elsewhere online.  My original comments were primary to:
1) I get the sense my company is not unique in our problems here given
these discussions and that lack of clarity I'm finding online.  So as
others stated here, I think the vast majority of software is likely in the
same place here and simply offering support to that feedback.
2) Expressing our need/desire to further delay the complete removal of
rearguard as it relates to: *"The TZ Coordinator is empowered to decide, as
the designated expert, appropriate changes, but SHOULD take into account
views expressed on the mailing list."*
3) I've been recently tasked with trying to figure this all out and the
impact to my company, so indeed this is precisely why I came to this
group/discussion to *"... **take the time to understand enough about time,
politics, design, and programming, despite the myriads of articles and
posts about such mistaken beliefs".*

[1] https://data.iana.org/time-zones/tz-link.html
[2] http://www.webexhibits.org/daylightsaving/b2.html
[3] https://www.timeanddate.com/time/zone/ireland/dublin
[4] https://mm.icann.org/pipermail/tz/2018-January/025836.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190531/0a45dc37/attachment.html>