[tz] Did Greenland abolish daylight saving from 2024 on?

Sat Nov 18 17:39:42 UTC 2023

I hope we do not overlook the fact that the term "standard" is ambiguous.

For example, it is always "standard time" in London, regardless if DST 
is in effect or not.

Indeed, the common use of the terms in the USA of, for example, "Eastern 
Standard Time" v.s. "Eastern Daylight Time" is in direct contradiction 
to the USA law itself which states:

PUBLIC LAW 89-387-APR. 13, 1966, AN ACT
To promote the observance of a uniform system of time throughout the 
United [S. 1404] States.
https://www.govinfo.gov/content/pkg/STATUTE-80/pdf/STATUTE-80-Pg107.pdf

SEC. 3. (a) During the period commencing at 2 o'clock antemeridian
on the last Sunday of April of each year and ending at 2 o'clock
antemeridian on the last Sunday of October of each year, the standard
time of each zone established by the Act of March 19, 1918 (15 U.S.C.
261-264), as modified by the Act of March 4, 1921 (15 U.S.C. 265),
shall be advanced one hour and such time as so advanced shall for the
purposes of such Act of March 19,1918, as so modified, be the standard
time of such zone during such period;

The USA law is consistent with international specifications, such as ISO 
8601:

INTERNATIONAL STANDARD
ISO, 8601-1, First edition, 2019-02

3.1.1.14
standard time
time scale (3.1.1.5) derived from UTC (3.1.1.12), by a time shift 
(3.1.1.25) established in a given location by the competent authority
EXAMPLE 1 Some standard times do not vary within a year, such as US 
Eastern Standard Time (EST), US Eastern Daylight Time (EDT), Australia 
Western Standard Time (AWST), China Standard Time (CST), Hong Kong 
Standard Time (HKT), Korea Standard Time (KST) and Japanese Standard 
Time (JST).
EXAMPLE 2 Some standard times vary within a year, such as US Eastern 
Time (ET) and Australian Central Standard Time (ACST).
Note 1 to entry: The time shift of a standard time may vary in the 
course of a year, such as due to daylight savings.
[SOURCE: IEC 60050-113:2011, 113-01-17, modified — The original NOTE has 
been deleted; EXAMPLE 1 and 2 and Note 1 to entry has been added.]

The "familiar" use of the term "standard" as typically understood in the 
USA and elsewhere has crept into Posix-time and TzDb, and is ambiguous 
and misleading in the context of international local time terminology.

Those on this list probably understand what "STDOFF" means in the 
context of TzDb, and that's clear enough to those experts. But to 
interpret this to mean "standard offset" may be a misunderstanding.

-Brooks

On 2023-11-17 6:18 PM, Guy Harris via tz wrote:
> On Nov 17, 2023, at 2:47 PM, Paul Eggert<eggert at cs.ucla.edu>  wrote:
>
>> On 2023-11-17 11:34, Guy Harris wrote:
>>
>>> The former would mean that "Daylight Savings Time", in POSIX, is always a time when clocks are turned forward, i.e. is always "summer time", even if that means that "standard time" and "Daylight Savings Time" are in effect at the same time.
>> That doesn't sound right, as POSIX says that in a TZ setting like TZ='IST-1GMT0,M10.5.0,M3.5.0/1' IST (+01) is standard time and GMT (+00) is daylight saving time.
> I.e., "the latter is true", as per your earlier mail.
>
> It's not "right" in the sense of being, apparently, what POSIX intends, but it's definitely "right" as in meaning
>
> 	"daylight saving time" could either be a time when the clock is turned forward from standard time *or* could *be* standard time, with the clocks being turned *backwards* from standard time for the winter
>
> which, as noted, is, in fact, different from
>
> 	"daylight saving time" can refer to a period in which the clock is turned *backwards* from standard time
>
>>> Do they explicitly define "Daylight Savings Time" in this fashion in some place?
>> There's no entry "Daylight Saving Time" in the POSIX glossary. However, the above is clear from POSIX's spec for the TZ environment variable.
> There are people to whom it's clear from the spec.  However, given that the current spec says
>
> 	Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard (std) or the alternative (dst -such as Daylight Savings Time) timezone. Only std is required; if dst is missing, then the alternative time does not apply in this locale.
>
> it is not clear to me from the current spec.
>
>>> I like the term "alternative"
>> The term "alternative time" was a POSIX invention, as I think ISO C has always called it "daylight saving time". However, this invention seems to have caused more confusion than it's cured, as Draft 3 of the next POSIX standard has gone back to saying "Daylight Saving Time" and does not mention "alternative time" there.
> Then perhaps it's clearer from Draft 3 than it is from the current SUS.
>
>>> The only way in which I could see it being read as assigning a meaning to "Daylight Savings Time" is indirectly, by speaking of "std" and "dst" as fields in the TZ environment variable setting (rather than speaking of "std" and "alt"), as "dst" suggests that it refers to "Daylight Savings Time", and thereby suggesting that "Daylight Savings Time" is an alternative to "standard time".
>> There's no confusion there. If you say TZ='UTC0' then UTC is the abbreviation for standard time and tm_isdst must be zero. Similarly for TZ='IST-1GMT0,M10.5.0,M3.5.0/1', where tm_isdst must be zero for IST and  and positive for GMT. There no plausible way to read POSIX otherwise, and this is independent of what non-POSIX sources say about "daylight saving time".
> This has been rather a lot of effort to construct a long line of reasoning to demonstrate what "Daylight Saving[s] Time" means in the POSIX spec.
>
> Would it not be a *lot* better if they just Defined. The. Damn. Thing., explicitly indicating that it does not always refer to what a fair number of people around the world think of as "Daylight Saving[s] Time"...
>
> ...especially given the email to the list from late 2017 to early 2018, in threads with subject lines such as "Irish Standard Time vs Irish Summer Time", "OpenJDK/CLDR/ICU/Joda issues with Ireland change", "[PROPOSED] Support zi parsers that mishandle negative DST offsets", etc., which contained a fair bit of pushback against the change to Irish time in the tzdb.
>
> Once the language lawyering gets down to this level, it *really* seems to me that POSIX should just bypass the language lawyering and explicitly indicate, in as many words, that tm_isdst should have a positive value when "standard time" is not in effect, or something such as that.
>
>>> Is there *any* place where non-computer-nerds and non-time-nerds speak of "daylight saving time" being in effect during the winter?
>> Most sources that go to that level of precision can plausibly be called the speech of time or computer nerds (and this includes the Wikipedia page you just edited :-).
> What level of precision is that?  The level of precision in which Ireland is on "Daylight Saving Time" during the winter?
>
> If so, I think that further suggests that POSIX using "Daylight Saving[s] Time" to mean "time is shifted in, either forward *or* backward, from 'standard time'", without an explicit statement to that effect, is Not A Good Thing, as, at least from the two pages I found in the .ie domain, that does *not* appear to obviously be how the Irish use the term "Daylight Saving Time".
>
>> That being said, I have seen winter time called "daylight saving" in the context of the rare places that observe winter time. See, for example, my 2017-04-09 comment about Namibia in the 'africa' file.
> Well, in the context of one of those places.  What about Ireland?  Or do we have a split decision here, still *further* indicating that the meaning of "Daylight Saving[s] Time" in common usage is not sufficiently regular as to make it not require an explicit definition in a standards document?
>
> Anyway, time to go file Another Austin Group Bug about this, asking for an explicitly definition in the glossary, just as "seconds since the Epoch" has (which is useful, given that it does not represent a count of SI seconds that have elapsed since the Epoch).
>
>