[tz] Extra transition for Europe/London with 2023d

[Guy Harris]

On Jan 6, 2024, at 3:37 PM, Stephen Colebourne via tz <tz at iana.org> wrote:

> On Sat, 6 Jan 2024 at 23:00, Guy Harris <gharris at sonic.net> wrote:
> 
>> what was the rationale for exposing them both?  Was there a situation where a Java library or application needed that information?
> 
> So people can use them?
> https://stackoverflow.com/questions/1060479/determine-whether-daylight-savings-time-dst-is-active-in-java-for-a-specified

What they're doing is

	I have a Java class that takes in the latitude/longitude of a location and returns the GMT offset when daylight savings time is on and off. I am looking for an easy way to determine in Java if the current date is in daylight savings time so I can apply the correct offset.

and, in answer to an obvious next question, more of what they're doing is

	Currently I am retrieving the time zone information using the GeoTools library and a shapefile provided by the National Atlas of the United States (nationalatlas.gov/mld/timeznp.html). Fortunately this provides me with some additional information - primarily the time zone symbol which is 2 or 4 digits (i.e AL, EA, EAno, etc). Unfortunately this value doesn't correspond to those used by Java time zones although I could perform this mapping manually. Ideally I'd like a solution that would work if I replaced this file with a world time zone shapefile but that might be too ambitious.

The answers point out that you're going to need the "Java time zone" anyway - the top answer suggests using inDaylightTime(), and points out that "A server trying to figure this out for a client will need the client's time zone."  If you have the relevant time zone, however, converting the current date to what I'm presuming is local time for whatever time zone that is, you can just use getOffset() to get the offset and not waste time caring about DST.

I.e., their belief that they need to be able to determine whether DST is active may be based on ignorance of one or more of 1) the getOffset() method of a TimeZone or 2) the fact that they're going to need a TimeZone *anyway* to determine whether DST is active.

And the information I was asking about was the standard offset and the actual offset; they're trying to determine the actual offset, and, once you have that, the standard offset isn't useful.  The problem is that they're trying to determine the actual offset in a roundabout way, by getting the standard offset, somehow determining what the offset would be in DST (probably by making a not-necessarily-valid assumption about DST shifting time one hour ahead), and then determining whether DST is in effect or not.  If the latter is done with inDaylightTime(), I infer that the java.time *implementation* of that method gets the standard and actual offsets and compares them, but that could equally well be done by using a TZif file that provides both a "what should tm_isdst be set to" value and a "what should inDaylightTime() return" value, without the standard offset being provided by the TZif file.

So, are there any cases where code would need information such as is provided by getRawOffset() for reasons *other* than "I'm trying to implement something that I could just do by calling the appropriate java.time method rather than duplicating what it does"?

And are there any cases where code would need information such as is provided by inDaylightTime() for reasons other than the aforementioned?

> isDaylightSavings() returns true in summer for Dublin in Java - always has done.

So I presume from that answer that isDaylightSavings(some time) is not always the same as the tm_isdst value in the structure returned by localtime(some time).

If so, why was it decided to have it work differently?