[tz] isdst bug Europe/Dublin (tzdb-2019c)

[Guy Harris]

On Dec 10, 2019, at 3:02 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 12/7/19 9:21 AM, Stefan Rueger wrote:
>> I think it's neater if the time stretches with the larger GMT values are considered DST.
> 
> It is a controversial area because there are two competing objectives: having standard time be the standard UT offset ('std' in POSIX) vs having DST's offset be greater than standard time's. As noted in the 'europe' file, in a comment from Joseph S. Myers (2005-01-26):
> 
> "(Note that the time in the Republic of Ireland since 1968 has been defined in terms of standard time being GMT+1 with a period of winter time when it is GMT, rather than standard time being GMT with a period of summer time being GMT+1.)"
> 
> and we eventually went with that interpretation, as opposed to the one you suggested.

I.e., it *is* DST, except that the "S" stands for "spending" rather than "saving". :-)

Either that, or "S" stands for "shifting", in both the case of shifting the clock forward from standard time in the spring and the case of shifting the clock *backward* from standard time in the autumn.  (That also has the advantage of not claiming anything's "saved".)

C18 says that

	Some functions deal with local time, which is the calendar time expressed for some specific time zone, and with Daylight Saving Time, which is a temporary change in the algorithm for determining local time. The local time zone and Daylight Saving Time are implementation-defined.

and that

	The value of tm_isdst is positive if Daylight Saving Time is in effect, zero if Daylight Saving Time is not in effect, and negative if the information is not available.

which leaves the interpretation to the implementation, as it doesn't say whether the time when the temporary change is *not* in effect must be the legally-defined "standard time" or not, nor whether the "temporary change" must set the clock forward.

POSIX appears not to disallow a TZ setting in which the "dst" offset is less than the "std" offset, unless I'm missing something, so, again, I'm not sure any standard forbids setting the clock *backwards* for "Daylight Saving Time".