The public information on the what has been decided regarding the Greenland timezone in the actual legislation, has been confusing to say the least. Even local news outlets seem to have either misunderstood the change, or reported on it with insufficient detail to clear things up. Unfortunately, this confusion has spilled over to the international press. The mail from the prime minister's office, is pretty clear however: Greenland (America/Nuuk) will keep observing DST but move from -03/-02 to -02/-01 by not changing the clocks in the fall of 2023. This is what's in TZDB today, so we should be good. On 01/04/2023 05.15, Jacob Pratt wrote:

There was an email to this list on March 15 from the Prime Minister's office. It was quite clear, and even included a table demonstrating DST resuming next year.

While I saw the numerous articles as well, the only conclusion I could reach is that every single one was (amazingly) wrong.

On Sat, Apr 1, 2023, 03:13 Paul Eggert via tz <tz@iana.org> wrote:

This week several English-language news sources reported that Greenland has moved its clocks forward for the last time. These reports disagree with current TZDB[1], which follows Thomas M. Steenholdt's December email[2] saying that although in November Greenlanders voted to not fall back this fall, they also voted to continue to observe daylight saving time (DST) next year, effectively moving their time zone one hour east instead of abolishing DST.

There's no disagreement about timekeeping this year. The first point of disagreement is March 30, 2024 at 23:00, when TZDB says Nuuk, Greenland will spring forward to 24:00, whereas the recent news reports say clocks will neither spring forward nor fall back during 2024.

So who's right: Steenholdt in December, or these several recent news reports? Currently TZDB goes with Steenholdt. After all, he cited the relevant Greenland legislation and his email address ends in ".gl". I suppose another possibility, though, is that Greenland's government has changed its mind since November. However, if so I'd like to see citations to the newer legislation.

The earliest recent news story I found on this topic was a week ago by Lebawit Lily Girma[3], senior travel news reporter for Bloomberg Pursuits. I'm taking the liberty of bcc'ing Girma to see if she can help get to the bottom of the situation.

[1]: https://iana.org/tz [2]: https://mm.icann.org/pipermail/tz/2022-December/032402.html [3]: Girma LL. Greenland Solves the Daylight Saving Time Debate. Bloomberg. 2023-03-24. https://www.bloomberg.com/news/articles/2023-03-24/greenland-keeps-daylight-...

Here are some of the other news reports I found.

Greenland to stay in daylight saving time forever. AP. 2023-03-27. https://apnews.com/article/greenland-daylight-saving-summertime-utc-gmt-3b5b...

Martin M. Greenland is keeping daylight saving time permanently. NPR. 2023-03-28. https://www.wunc.org/2023-03-28/greenland-is-keeping-daylight-saving-time-pe...

Selcho M. Here’s why Greenland is permanently keeping daylight saving time. Deseret News. 2023-03-28. https://www.deseret.com/u-s-world/2023/3/28/23660379/why-greenland-keeping-d...

Jerusalem Post staff. Greenland changed their clocks to daylight savings for the last time. Jerusalem Post. 2023-03-29. https://www.jpost.com/international/article-735751

Carpineti A. Greenland Has Changed Its Clocks For The Last Time, Embracing Daylight Savings Forever. IFLScience. 2023-03-29. https://www.iflscience.com/greenland-has-changed-its-clocks-for-the-last-tim...

On 2023-04-01 00:15, Jacob Pratt wrote:

There was an email to this list on March 15 from the Prime Minister's office. It was quite clear, and even included a table demonstrating DST resuming next year.

Oh, thanks, I'd quite forgotten about that March 15 letter. It seems definitive.

While I saw the numerous articles as well, the only conclusion I could reach is that every single one was (amazingly) wrong.

Yes, and none gave sources. I've written two of the authors of the wrong articles, namely, Bloomberg's Lebawit Lily Girma yesterday and IFLScience's Dr Alfredo Carpineti three days ago. I have seen no replies yet. Just now I wrote to the AP and to NPR, which are the biggest news organizations on my list. I hope they issue corrections.

On 4/4/23 17:56, Thomas M. Steenholdt wrote:

Compared to the current tzdb definition, the clock aligns perfectly, but the isdst-flag does not.

Thanks for reporting that. I installed the attached, which is your data patch plus some commentary.

On 11/13/23 03:12, Thomas M. Steenholdt wrote:

So for better timezone consistency, I would suggest to that we simply drop this change to rigidly fix is_dst, and use what is in 2023c. This follows the intention of the timezone change

As I understand things, Greenland Prime Minister Múte Bourup Egede said "Greenland will not switch to Daylight Saving Time this year", so the intent was that tm_isdst should be zero all year. As you say, real software by and large doesn't care about tm_isdst any more. This is why we haven't bothered to issue a new TZDB release yet - nobody cares in the real world. But eventually when the next TZDB release comes out I'd like the tm_isdst flag to reflect better the intended rules by Greenland's government, as we might as well do things right if it's easy. I expect will care about this except us TZDB nerds. The NEWS file does need a fix now, though; proposed patch attached.

On Nov 13, 2023, at 3:47 PM, Paul Eggert via tz <tz@iana.org> wrote:

As you say, real software by and large doesn't care about tm_isdst any more. This is why we haven't bothered to issue a new TZDB release yet - nobody cares in the real world. But eventually when the next TZDB release comes out I'd like the tm_isdst flag to reflect better the intended rules by Greenland's government, as we might as well do things right if it's easy. I expect will care about this except us TZDB nerds.

I see three ways in which tm_isdst can be used: 1) as an indication of whether something known as "daylight saving time" or "summer time" or something other than "standard time" is in effect; 2) as an indication of whether the offset-from-UTC is advanced from what it would be in winter; 3) as an index into the tzname[] array. Given that, in the real world, clocks do not all follow a simple "standard time" vs "daylight saving time" model, with, for example, the Moroccan adjustments for Ramadan and the Irish "we call what we get when we advance the clocks for summer 'standard time' and we call what we get when we turn back the clocks for winter 'winter time', rather than what most locales that follow that pattern do", I'd say that it'd be unwise to write code that does 1). 2) and 3) could be made to work, perhaps with some trickery to handle cases where, in the period 1970-present, the are more than to abbreviations for tzname[], e.g. with the tzname[] array being set in such a way that it works for the last "struct tm" values supplied by the library, and thus changed multiple times.

On Nov 14, 2023, at 12:32 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 2023-11-13 16:48, Guy Harris wrote:

...

I see three ways in which tm_isdst can be used: 1) as an indication of whether something known as "daylight saving time" or "summer time" or something other than "standard time" is in effect; 2) as an indication of whether the offset-from-UTC is advanced from what it would be in winter; 3) as an index into the tzname[] array.

(1) is the only thing that tzcode supports.

Including # From Paul Eggert (2018-02-15): # In January 2018 we discovered that the negative SAVE values in the # Eire rules cause problems with tests for ICU: # https://mm.icann.org/pipermail/tz/2018-January/025825.html # and with tests for OpenJDK: # https://mm.icann.org/pipermail/tz/2018-January/025822.html # # To work around this problem, the build procedure can translate the # following data into two forms, one with negative SAVE values and the # other form with a traditional approximation for Irish timestamps # after 1971-10-31 02:00 UTC; although this approximation has tm_isdst # flags that are reversed, its UTC offsets are correct and this often # suffices.... # # The following is like GB-Eire and EU, except with standard time in # summer and negative daylight saving time in winter. It is for when # negative SAVE values are used. For what it's worth, macOS Ventura 13.6's localtime() claims, in tm_isdst, that Ireland is on standard time, while Ubuntu 22.04's localtime() claims, in tm_isdst, that it's on DST.

(2) is incompatible with POSIX if by "advanced" one means "greater offset from UT", since POSIX requires so-called "negative" DST for TZ settings like TZ='IST-1GMT0,M10.5.0,M3.5.0/1', the current Irish practice.

So even POSIX, in effect, tells people "don't assume tm_isdst means 'this is daylight saving time'".

(3) might be made to work, but it'd mean that in most TZDB Zones, tm_isdst would be nonzero for timestamps that pretty much everybody would consider to be standard time. For example, tzdata says TZ='America/Detroit' has observed standard time with abbreviations "LMT", "CST", and "EST" in the past, and at most one of these could get tm_isdst==0.

POSIX does not appear to require that tzname[0] or tzname[1] retain the same values over time, and neither the macOS Ventura 13.6 version of tzcode: $ TZ=America/Indiana/Vincennes ./tzname 2006-04-03 tzname[0] = "EST" tzname[1] = "CDT" Current tz abbreviation = "CDT" $ TZ=America/Indiana/Vincennes ./tzname 2010-04-03 tzname[0] = "EST" tzname[1] = "EDT" Current tz abbreviation = "EDT" nor the glibc time zone code in Ubuntu 22.04: $ TZ=America/Indiana/Vincennes ./tzname 2006-04-03 tzname[0] = "CST" tzname[1] = "CDT" Current tz abbreviation = "CDT" $ TZ=America/Indiana/Vincennes ./tzname 2010-04-03 tzname[0] = "EST" tzname[1] = "EDT" Current tz abbreviation = "EDT" keep it having the same reason. And, for America/Detroit: $ TZ=America/Detroit ./tzname 1904-01-01 tzname[0] = "LMT" tzname[1] = "EDT" Current tz abbreviation = "LMT" $ TZ=America/Detroit ./tzname 1905-01-01 tzname[0] = "CST" tzname[1] = "EDT" Current tz abbreviation = "CST" $ TZ=America/Detroit ./tzname 1915-05-16 tzname[0] = "EST" tzname[1] = "EDT" Current tz abbreviation = "EST"

Besides, with tzcode time zone abbreviations should not be deduced by inspecting tm_isdst. Instead, one should use strftime or (if available) the tm_zone member of struct tm. tm_zone is better if it is available, which I hope will be required by the next POSIX version.

Requiring tm_zone may cause binary-compatibility issues for OSes that don't currently have it and for which the supplier seeks Single UNIX Specification certification. For those OSes: Solaris's Single UNIX Specification certification has lapsed, so they may not have to add it; AIX is still certified; HP-UX *probably* doesn't have tm_zone (I don't even know if they're using the tzdb - a long time ago, I seem to remember they had their own database), but, given that they haven't said anything about an x86-64 port, and seem to be planning on offering x86-64/Linux servers with an environment in which to run HP-UX Itanium applications, I suspect HP-UX's future is limited. If necessary, they *could* handle it. macOS Ventura's compat(5) man page says: In order to provide both legacy and conformance versions of functions, two versions of affected functions are provided. Legacy variants have symbol names with no suffix in order to maintain ABI compatibility. Conformance versions have a $UNIX2003 suffix appended to their symbol name. These $UNIX2003 suffixes are automatically appended by the compiler tool-chain and should not be used directly. which was how Apple handled some cases where POSIX conformance (starting in Leopard) would break binary and source compatibility with existing programs. That would raise the question of how long-lived a struct tm is. For example, what happens if you call localtime(), save the result, set the TZ environment variable in your program to some other tzid, call tzset(), and try to use the tm_zone member of the struct tm? If tzset() frees all the data it has before loading new data, that would include freeing time zone abbreviations.

This is why <https://data.iana.org/time-zones/theory.html#vestigial> says "tm_isdst is almost never needed".

And, in fact, says: The tm_isdst member is almost never needed *and most of its uses should be discouraged in favor of the abovementioned APIs*. so it's not just descriptive, it's prescriptive, which is a Good Thing.

Its only plausible use these days is when calling mktime, and even then it's flaky.

The C and POSIX standards should probably warn that using anything other than -1 (or any other negative number) for tm_isdst may not give you what you think you want. The SUS currently says A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. I guess "presume initially" is somewhat weasel-wordish and could be read as not saying too much about what will happen, but something stronger might be better.

On Nov 16, 2023, at 6:29 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 11/16/23 14:43, Guy Harris wrote:

...

...

(2) is incompatible with POSIX if by "advanced" one means "greater offset from UT", since POSIX requires so-called "negative" DST for TZ settings like TZ='IST-1GMT0,M10.5.0,M3.5.0/1', the current Irish practice. So even POSIX, in effect, tells people "don't assume tm_isdst means 'this is daylight saving time'".

Not sure what is meant by "in effect". POSIX says "The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available." <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html>

So the intent of POSIX is that tm_isdst>0 means daylight saving time. The DST offset from UT need not be greater than the standard-time offset. POSIX (and TZDB) even allow the two offsets to be equal, though there's not much use for that.

...which means that the phrase "Daylight Savings Time" in the POSIX standard refers to something that's not exactly the same as "daylight saving time" as generally understood, i.e. it doesn't necessarily mean "the time that's in effect during summer and possibly some close-to-summer dates in spring and autumn, if clocks are adjusted twice a year, with the clock setting during summer and blah blah blah being ahead of the clock setting during the rest of the year". or...). POSIX at least defines "seconds since the Epoch", to make it clear that it doesn't mean the number of SI seconds that have elapsed since the Epoch; it does not appear to define "Daylight Savings Time", but, if it uses it, it should do so, given, for example, the case of the Republic of Ireland.

...

Requiring tm_zone may cause binary-compatibility issues for OSes that don't currently have it and for which the supplier seeks Single UNIX Specification certification.

There definitely are binary compatibility issues, since growing a struct is a hassle. This is true regardless of whether the system is SUS certified.

But if the system isn't SUS-certified, and the supplier doesn't intend to have it be SUS-certified, they can just say "too bad, POSIX may require tm_zone, but we don't do POSIX, so we're not doing tm_zone. That's how SUS certification matters here. Apple has no problem, as they've had tm_zone since, as far as I know, Day One. (Maybe it wasn't in Rhapsody or Mac OS Server 1.0, but I think it was there going all the way back to 10.0/Cheetah. The Libc project source for 10.0 has it; I'm not sure what project has the header files.) As for non-SUS-certified systems: The *BSDs aren't going for SUS certification, but they've had it for ages - possible ever since they picked up the tz code. GNU libc currently has it, albeit with a #define to control whether to pollute the namespace with a structure member named tm_zone or to slap enough underscores in front of tm_zone to make it safe, so many Linux distributions have it. I don't know whether any of the alternative C libraries, such as musl, have it. (EulerOS and Inspur K-UX were certified Linux distributions at one point, but they didn't renew the certification.) And as for the biggest non-embedded Linux distribution of all, bionic appears to have tm_zone (by virtue of libc/include/time.h 1) having it in struct tm and 2) defining TM_ZONE to be tm_zone).

...

That would raise the question of how long-lived a struct tm is.

That's reasonably straightforward. With localtime the char * member's lifetime survives until TZ is modified; this is what Draft 3 of the next POSIX standard says. On platforms with localtime_rz the member survives until the corresponding timezone_t is tzfree'd.

So they took the simplest approach; that means that code using tm_zone needs to be careful with those strings, but that's *already* the case, as no stronger guarantees are, as far as I know, offered either by the tz code or the equivalent in various other libc implementations. (Now when's Microsoft going to join the party - and not just in the Linux distributions running atop WSL?)

On Nov 17, 2023, at 12:06 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 2023-11-16 19:35, Guy Harris wrote:

...

On Nov 16, 2023, at 6:29 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

...

...which means that the phrase "Daylight Savings Time" in the POSIX standard refers to something that's not exactly the same as "daylight saving time" as generally understood, i.e. it doesn't necessarily mean "the time that's in effect during summer and possibly some close-to-summer dates in spring and autumn, if clocks are adjusted twice a year, with the clock setting during summer and blah blah blah being ahead of the clock setting during the rest of the year".

If you're accustomed to the United States then that's indeed what "daylight saving time" has meant. And given the US's influence it's not surprising that the usage is common elsewhere. However, it's not universal, and POSIX and TZDB support the more-general case.

So does POSIX's use of "Daylight Savings Time" mean that "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? Or does it really mean that "daylight saving time" can refer to a period in which the clock is turned *backwards* from standard time?

The earliest use of negative DST that's recorded in TZDB is Czechoslovakia during winter 1946/1947. That's also the earliest use recorded in the Wikipedia page on negative DST <https://en.wikipedia.org/wiki/Winter_time_(clock_lag)>

The image of the Czechoslovak public journal about that says "zákon o zimnim çase", which Google Translate translates to "winter time law". Ireland also, as I remember, refers to the time when clocks are turned backwards as "winter time". The Namibian newspapers used as citations also speak of "winter time". So, for "standard time is the time in the summer, and clocks are turned backward in the winter" locales, I'm not seeing "daylight saving time" being used either for the period when the clocks are turned forward or for the period when the clocks are turned backward.

- a page that you've edited.

And I just edited it again now, to change It is a form of [[daylight saving time]] which is the opposite compensation to the summer time (+1, +2). to It is a form of daylight saving time in which standard time is in effect during summer months, rather than the usual case where standard time is in effect during winter months. to clarify it ("the opposite compensation to the summer time" is "opposite" only in the sense that standard time is ahead of non-standard time rather than being behind it - it's not "opposite" in the sense of "the clocks go forward in the winter and backward in the summer", which I see as an equally valid sense of "opposite", and one which I suspect might be the sense most ordinary folk, as opposed to time nerds, would see "opposite" in this case). (And if anybody claims that it means that daylight saving time is in effect during the winter, I'm going to {{cn}} the heck out of that claim.)

On Fri 2023-11-17T11:26:00+0000 Clive D.W. Feather via tz hath writ:

Wasn't there a place in the shadow of a mountain where the clocks were put *forward* in the winter to make it light when people needed, while in the summer the sun shone over the top of the mountain so it did't matter?

That was Palm Springs, California in 1946 https://www.desertsun.com/story/life/2017/12/27/palm-springs-struggle-daylig... -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

Date: Fri, 17 Nov 2023 01:00:58 -0800 From: Guy Harris via tz <tz@iana.org> Message-ID: <05C16FF2-AC33-4943-8495-D4F53FF4D9A4@sonic.net> | in which standard time is in effect during summer months, In reality, standard time, is, and should be, simply the time which applies now, whenever now is. Its offset from UTC might vary during the year, but it is all standard time. For absurd reasons, people like to label the time based upon the offset (sometimes) and pretend that one offset is the real time, and another is a variation, but that's all gibberish. Unless you're defining LMT as being the standard time (and no-one does that any more I think), there is essentially nowhere where there's a "correct" time - and even there, who says that the middle of the night is required to be 00:00 and the middle of the day 12:00 - all this is just a human added convention, and as that, humans can modify it however they (maybe we, I might be human) want. The label "Daylight Saving Time" is, and always was, propaganda - its intent is to bring forth a notion of "saving" - which is generally thought to be a good thing, whatever is being saved (lives, the planet, species X, ... and apparently "daylight" - though daylight neither is, can be, or needs to be, saved). It is all just useful for a semi-literate audience who are unable to actually see through the rhetoric. If names are needed (which they're not really) for different UTC offsets in some area, summer/winter time (which is how the division is, very very roughly, generally made) is a much better nomenclature. | (And if anybody claims that it means that daylight saving time is in | effect during the winter, I'm going to {{cn}} the heck out of that claim.) Why can't it be? If you really insist on applying the propaganda - daylight is being saved during the late afternoon/evening period so it can be used to better effect the following morning. kre

(Happily, we don't live in the kind of world where you have to pay interest on it.)

Hush now... don't give any governmental agencies or reps any kind of an idea like this... that is something for sure they would take up and run with... -----Original Message----- From: tz <tz-bounces@iana.org> On Behalf Of Philip Paeps via tz Sent: Friday, November 17, 2023 7:59 AM To: Robert Elz <kre@munnari.OZ.AU> Cc: tz@iana.org Subject: Re: [tz] Did Greenland abolish daylight saving from 2024 on? Alert: This is an external email. On 2023-11-17 19:41:43 (+0800), Robert Elz via tz wrote:

For absurd reasons, people like to label the time based upon the offset (sometimes) and pretend that one offset is the real time, and another is a variation, but that's all gibberish. Unless you're defining LMT as being the standard time (and no-one does that any more I think), there is essentially nowhere where there's a "correct" time - and even there, who says that the middle of the night is required to be 00:00 and the middle of the day 12:00 - all this is just a human added convention, and as that, humans can modify it however they (maybe we, I might be human) want.

Notably this convention does not apply in e.g. East Africa. Swahili speakers consider 00:00 to be the time the sun rises. Around the equator, this happens about six hours after midnight. Consequently, at 08:00 East Africa Time (UTC+3) it is "two o'clock" in Swahili.

The label "Daylight Saving Time" is, and always was, propaganda - its intent is to bring forth a notion of "saving" - which is generally thought to be a good thing, whatever is being saved (lives, the planet, species X, ... and apparently "daylight" - though daylight neither is, can be, or needs to be, saved). It is all just useful for a semi-literate audience who are unable to actually see through the rhetoric.

I've always argued it's more of a daylight "loan" than "saving". After all, you have to pay back your daylight later the same day. (Happily, we don't live in the kind of world where you have to pay interest on it.)

If names are needed (which they're not really) for different UTC offsets in some area, summer/winter time (which is how the division is, very very roughly, generally made) is a much better nomenclature.

I agree with this. Unfortunately, it doesn't look like tilting that windmill is having much of an effect. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises

On Nov 17, 2023, at 8:35 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 2023-11-17 01:00, Guy Harris wrote:

...

So does POSIX's use of "Daylight Savings Time" mean that "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? Or does it really mean that "daylight saving time" can refer to a period in which the clock is turned *backwards* from standard time?

The latter is true. (I don't fully understand what you mean by the former, or why it differs from the latter.)

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. The latter would mean that "Daylight Savings Time", in POSIX, could either be a time when clocks are turned forward or a time when clocks are turned backward, i.e. it could either be "summer time" or "winter time". Do they explicitly define "Daylight Savings Time" in this fashion in some place? 8.3 "Other Environment Variables" says, in its description of TZ: std and dst 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. which speaks of "standard" and "alternative" timezones. They don't state what "standard" means; it might be useful if POSIX were to indicate that this term refers to something such as the timekeeping specified as a "standard" by law. I like the term "alternative", as it's not the problematic-in-any-ways "daylight saving time" and "daylight savings time", and as it does not commit to the alternative to always be "summer time", allowing it to be "winter time". That merely speaks of "Daylight Savings Time" as an *example* of an "alternative". 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". The problem I have with that is that, as far as I know, in the regions where terms of the form "daylight saving[s] time" are used, it exclusively refers to times when clocks are turned forward, i.e. to what other regions call "summer time", so, in the absence of an explicit definition of "Daylight Savings Time", people might assume it refers to clocks-turned-forward-time, in which case "Daylight Savings Time" would not be in effect in Ireland during the winter. I.e., the problem with

If you're accustomed to the United States then that's indeed what "daylight saving time" has meant. And given the US's influence it's not surprising that the usage is common elsewhere. However, it's not universal, and POSIX and TZDB support the more-general case.

is that, as far as I know, in those locations where clocks are turned backward from "standard time" in the winter, rather than forward from "standard time" in the summer, that's referred to as "winter time", not "daylight saving time" or any such term, so it's not clear that the use of "daylight saving time" etc. to refer to turning clocks forward from "standard time" in the summer is *not*, in fact, universal. See, for example: https://www.abcschoolsupplies.ie/why-do-the-clocks-change in which "daylight saving time" is used in the US sense, and https://safetymatters.ie/news/daylight-saving-time-dst-is-related-to-health-... which says both The time change in winter, commonly referred to as “Daylight Saving Time” (DST) or “Standard Time,” which I find difficult to interpret, and both When DST begins in the spring, ... and When DST ends in the winter ... which uses DST in the US sense. Is there *any* place where non-computer-nerds and non-time-nerds speak of "daylight saving time" being in effect during the winter? If not, then perhaps POSIX, to avoid the need to ask questions of its maintainers as to what they mean, should either define what "Daylight Savings Time" means (whether it's intended to mean "summer time" or it's intended to mean "alternative time" as in "not standard time"), *even if that means it doesn't correspond to the US-style usage* (it might not be a *wise* choice to use it in that fashion, as it appears to be used in that fashion even in at least some Irish web sites), or should use "alternative time" and define *that* to mean "not standard time", and perhaps explicitly indicate that this could mean either "summer time" or "winter time".

Say you're in Ireland and set TZ='IST-1GMT0,M10.5.0,M3.5.0/1'. POSIX says that tm_isdst must be positive when clocks are turned backwards from standard time. This longstanding POSIX requirement is independent of whatever TZDB does.

I.e., POSIX is saying that tm_isdst must be positive during a time that at least some Irish web sites consider not to be Daylight Saving Time. Or, alternatively, that a value for tm_isdst that's positive could mean that the time in question is not DST, not that it is DST.

On Nov 17, 2023, at 2:47 PM, Paul Eggert <eggert@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).

On 2023-11-17 20:44, Paul Eggert via tz wrote:

On 2023-11-17 15:18, Guy Harris wrote:

...

It's not "right" in the sense of being, apparently, what POSIX intends, but it's definitely "right" as in meaning

Sorry, I'm lost, as I don't rightly know what you meant "'right'" here, and I don't know what you think POSIX intends.

...

it is not clear to me from the current spec.

I've tried to explain but apparently have failed so far. If you file a bug report with the Austin Group please let me know its coordinates; I can try to clarify there. I'm confident of the thrust of the interpretation I gave - though I guess I shouldn't be so confident in the quality of my explanation so far....

...

...

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?

Yes, that sort of thing. Hardly anybody cares about this stuff except time nerds.

...

Well, in the context of one of those places.  What about Ireland?

Ireland too. Here's an example:

https://www.boards.ie/discussion/2057906815/eu-to-recommend-abolishing-dst/p...

It says, "Technically speaking, Irish Standard Time is UTC+1, we are on daylight saving time when the clock goes back.... Both the UK and European countries move to a +1 offset for summer time. Ireland technically moves to a -1 offset from UTC+1 for winter time. So in practical terms were on the same time as the UK due to the opposite offset."

There are examples the other way, too. More common, I think, is that people in Ireland say "summer time" and "winter time" instead of "standard time" and "daylight saving time", as this happily avoids any confusion about which of Greenwich Mean Time and Irish Standard Time is standard time, and which is daylight saving time.

As the second Irish article says: 'The time change in winter, commonly referred to as “Daylight Saving Time” (DST) or “Standard Time,”' so they mean the same in normal language in that zone, and possibly in other zones in similar situations. That demonstrates why DST is now inadequate as a technical term and ALT would be better, without twisting the meaning of DST from what it means in normal language, requiring a lot of explanation which few will read and fewer understand. We could also add Daylight Loan Time to the glossary for more "clarity" ;^> Better to use summer/winter, which is a more global usage whereas DST is mainly US/North American, and works regardless of hemisphere, as time changes are useless without some seasonal variations in daylight hours. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

On Sat 2023-11-18T12:39:42-0500 Brooks Harris via tz hath writ:

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

The legal situation in the US is less clearly defined than that.

PUBLIC LAW 89-387-APR. 13, 1966, AN ACT SEC. 3. (a) During the period commencing at 2 o'clock antemeridian

That same "antemeridian" language persists in the 2005 revision of US law. That language made sense in 1966 because time was based on meridians, but even then the meridian for measuring UT[012] was known not to be the Greenwich meridian. In the 2005 revision the basis of UTC was not really even the meridian of UT1. If the ITU WRC this week agrees with the CGPM about the future of UTC then time will no longer be related to any meridian. Widespread agreement with high precision of the answer to "What time is it?" is imperative, but common language and legal language are imprecise and misleading. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

I agree. The point I was getting at is about the term "standard time". The law says: "...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;" Thus it is "standard time" whether or not DST is in effect. This is consistent with international practice but not with typical expressions such as "Eastern Standard Time" v.s. "Eastern Daylight Time". -Brooks On 2023-11-18 2:51 PM, Robert Elz via tz wrote:

Date: Sat, 18 Nov 2023 10:52:34 -0800 From: Steve Allen via tz <tz@iana.org> Message-ID: <20231118185234.GA23319@ucolick.org>

| On Sat 2023-11-18T12:39:42-0500 Brooks Harris via tz hath writ: | > I hope we do not overlook the fact that the term "standard" is ambiguous. | | The legal situation in the US is less clearly defined than that. | | > PUBLIC LAW 89-387-APR. 13, 1966, AN ACT | > SEC. 3. (a) During the period commencing at 2 o'clock antemeridian

You should read that as 2 a.m. as that's what it is saying. antemeridian means "before noon" and the full interpretation of it is "2 on the clock before noon" (ie: the clock shows 2, and it is before noon).

None of that has anything whatever to do with lines of longitude.

kre

ps: I truly wish we could get rid of the abominable habit of calling 12:00 (24 hour clock) as 12pm (12 hour clock) and 00:00 as 12am, 12:00 *is* the meridian, and so cannot be after it (not post meridian) nor can it be before it. And 00:00 is both 12 hours before, and 12 hours after (different) noons, so it is both 12am and 12pm, and so using either of those is meaningless. 12n (or nn or something) and 12mn make much more sense than 12am and 12pm. (On the other hand for 12:00:01 than am or pm makes perfect sense, depending which is meant).

On 2023-11-18 11:51, Robert Elz via tz wrote:

12n (or nn or something) and 12mn make much more sense than 12am and 12pm.

The traditional form is "12 m." for noon, where "m." stands for "meridies", i.e., neither ante nor post meridian. This abbreviation is mentioned in (among other places) the Chicago Manual of Style, which goes on to say "very few use that form. And the term 12:00 p.m. is ambiguous, if not illogical." See: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Usage/faq0061.htm... Computer nerds' strong preference for origin-zero counting have caused computer-based clocks to use 12 a.m. for midnight and 12 p.m. for noon, despite the latter being arguably "illogical". A bit of trivia: in Latin "meridies" also means "south" or "southward", because if you stood in ancient Rome at noon, the sun was in the south. This worked because Rome used local solar time, not mean solar time. Contrast ancient Room to today's Nuuk, Greenland where Stellarium says the Sun's azimuth at local noon today was about 163° and in the summer the Sun's noon azimuth can get down to around 130° - a long, long way from the 180° of true south. In this sense, ancient Roman timekeeping was a whole lot better than ours.

On 2023-11-18 1:52 PM, Steve Allen via tz wrote:

On Sat 2023-11-18T12:39:42-0500 Brooks Harris via tz hath writ:

...

I hope we do not overlook the fact that the term "standard" is ambiguous. The legal situation in the US is less clearly defined than that.

...

PUBLIC LAW 89-387-APR. 13, 1966, AN ACT SEC. 3. (a) During the period commencing at 2 o'clock antemeridian That same "antemeridian" language persists in the 2005 revision of US law. That language made sense in 1966 because time was based on meridians, but even then the meridian for measuring UT[012] was known not to be the Greenwich meridian. In the 2005 revision the basis of UTC was not really even the meridian of UT1. Ah yes.

I am careful to think of local time as offsets from UTC in the time domain. Its exact relation to longitude and solar time has become vague.

If the ITU WRC this week agrees with the CGPM about the future of UTC then time will no longer be related to any meridian. Or solar time.

Widespread agreement with high precision of the answer to "What time is it?" is imperative, but common language and legal language are imprecise and misleading. I think of it as "the fog of timekeeping".

-Brooks

-- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

On Nov 16, 2023, at 9:29 PM, Paul Eggert via tz <tz@iana.org> wrote:

Not sure what is meant by "in effect". POSIX says "The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available." <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html>

So the intent of POSIX is that tm_isdst>0 means daylight saving time. The DST offset from UT need not be greater than the standard-time offset. POSIX (and TZDB) even allow the two offsets to be equal, though there's not much use for that.

In light of the seemingly significant confusion and divergences of understanding around exactly what “Daylight Saving Time” means in various jurisdictions (e.g. Ireland vs. North America vs. ??), perhaps it's time to consider just setting tm_isdat=-1 in all zones that do not return a fixed offset for the entire year? While this would effectively mean the retirement that field, how much modern software actually makes use of it? There is precedent for something like this: the deprecation of the "struct timezone *tz" argument to gettimeofday() and settimeofday(). The man page for those functions on my Linux system (CentOS 7, man-pages-3.53.-5) has this to say about that field in the NOTES section: *** snip snip *** On old systems, the field tz_dsttime contains a symbolic constant (val‐ ues are given below) that indicates in which part of the year Daylight Saving Time is in force. (Note: this value is constant throughout the year: it does not indicate that DST is in force, it just selects an algorithm.) The daylight saving time algorithms defined are as fol‐ lows: [… list of historical timezone IDs omitted …] Of course it turned out that the period in which Daylight Saving Time is in force cannot be given by a simple algorithm, one per country; indeed, this period is determined by unpredictable political decisions. So this method of representing timezones has been abandoned. *** snip snip *** It strikes me that we’ve arrived at a similar place WRT the “is_dst” field: namely, that it is too simplistic a mechanism for describing actual ground truth in 2023. POSIX provides a way to tell applications unambiguously that “we don’t know”. Perhaps we should take advantage of that? Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | Never take two chronometers to sea. Always take one or three, | | otherwise you'll never be sure what time it is. | | | | -- Anonymous | |---------------------------------------------------------------------|

On Nov 17, 2023, at 12:58 PM, Guy Harris via tz <tz@iana.org> wrote:

If not, there does not appear to be any divergence of understanding mourned what "Daylight Saving Time" means between Ireland and North America.

...divergence of understanding *around* what "Daylight Saving Time" means...

On Nov 17, 2023, at 1:18 PM, Doug Ewell <doug@ewellic.org> wrote:

Guy Harris wrote:

...

Are there any people in Ireland who believe that "Daylight Saving Time" is observed during the winter?

I’ve always been led to believe that “Daylight Saving Time” (with or without the odious extra ‘s’) is North American and Australian terminology, and that Europeans instead use the term “summer time” to refer to an alternative time standard observed during some period that includes the summer.

That's the impression I have as well. And I think "summer time" is a better term, as 1) it doesn't make a bogus claim of "saving" anything and 2) it clearly indicates when it is in effect.

Given that, it may not be surprising if Irish writers equate the foreign term “Daylight Saving Time” with whatever time they observe in the summer, regardless of whether that time is “standard.”

The surprise, for me, is that they use the term "Daylight Saving Time" at all. Perhaps, in the Irish case. where "standard time" is observed in the summer and "winter time" is observed in the winter, they adopt the North American/Australian term because "summer time", for them, unlike for the rest of Europe, *is* "standard time", so they can't speak of "standard time" vs. "summer time".

On Nov 17, 2023, at 2:04 PM, Clive D.W. Feather <clive@davros.org> wrote:

Guy Harris via tz said:

...

The surprise, for me, is that they use the term "Daylight Saving Time" at all. Perhaps, in the Irish case. where "standard time" is observed in the summer and "winter time" is observed in the winter, they adopt the North American/Australian term because "summer time", for them, unlike for the rest of Europe, *is* "standard time", so they can't speak of "standard time" vs. "summer time".

My suspicion is that they're someone like me who just says "Oh, the clocks have changed *again*" and never refers - except in this sort of discussion - to "summer time" in that sense. The correct terms in the UK are actually "Greenwich Mean Time" and "British Summer Time".

Yes, and the terms in the US Pacific time zone are "Pacific Standard Time" and "Pacific Daylight Time", and "Pacific Daylight Time" is "Daylight Saving Time" in the "turn the clocks forward" sense. And "British Summer Time" contains the phrase "Summer Time". I guess it's *British* summer time, not the summer time or "Sommerzeit" or... those on the continent observe: https://www.hamburg.de/zeitumstellung/ "Sommerzeit und WinterzeitZeitumstellung 2023 In Deutschland wird zweimal im Jahr die Zeit umgestellt. Am letzten Sonntag im März erfolgt die Zeitumstellung von MEZ (bzw. Winterzeit) auf Sommerzeit und am letzten Sonntag im Oktober von Sommerzeit auf MEZ (bzw. Winterzeit)." or, as per Google Translate: "Summer time and winter timeTime change 2023 In Germany, the time is changed twice a year. On the last Sunday in March, the time change of CET (or winter time) to daylight saving time and on the last Sunday in October from daylight saving time to CET (or Winter time)." which appears to include Google Translate translating "Sommerzeit" idiomatically as "Daylight Saving Time", so maybe that's more like "Summer time and winter timeTime change 2023 In Germany, the time is changed twice a year. On the last Sunday in March, the time change of CET (or winter time) to summer time and on the last Sunday in October from summer time to CET (or Winter time)."

Peter Krefting via tz wrote in <dd2e53d1-4550-a9ff-b975-b734e8c6484e@softwolves.pp.se>: |Doug Ewell via tz: | |> I’ve always been led to believe that “Daylight Saving Time” (with or |> without the odious extra ‘s’) is North American and Australian |> terminology, and that Europeans instead use the term “summer time” |> to refer to an alternative time standard observed during some period |> that includes the summer. | |Indeed. In Scandinavia it is always "summer time" and "winter time". |(The only people using "normal time" or "standard time" are those of us |who want us to stop with the shenanigans of changing the clocks.) | |Before I started writing software on computers that had reliable |clocks in them, I had never heard about "daylight savings time". I want to note a psychological issue here. As far as i know people in the north have a high suicide rate, Finland especially. (However i did not look in all of that for almost twenty years, since beginning of September 2005 to be exact.) So either you are a hopeless Indian farmer in the fangs of Monsanto, or you are a Fin or another such poor soul. I think this thread already revealed the hope of the Stonehenge Brits to look at big LED lamps that shine in a warm white each and every day of the year (Yay!), but in the end my gut feeling says that Sunshine is still a bit different and preferable. In sofar "daylight saving" is a human engineering trick that is cheap but nice to have. Whoever did it is worth a worthy Noble price. (Thus not in these times, but maybe later again.) A nice SUNday everybody! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Peter Krefting via tz wrote in <4e590c51-10ed-6aec-f82d-ef01b72ab704@softwolves.pp.se>: |Steffen Nurpmeso via tz: |> In sofar "daylight saving" is a human engineering trick that is |> cheap but nice to have. Whoever did it is worth a worthy Noble |> price. (Thus not in these times, but maybe later again.) | |The problem with changing clocks and living up north is that it is |completely useless. In summer, I don't care if we get twilight between |02 and 04 or between 01 and 03, nights are still light. And in winter |I don't really care if it is dark from 14:30 or 15:30, days are still |dark. The only time it actually makes a difference is around the equinox. I would do it differently myself, for Germany, to have more light in the afternoon. (That is, if it would be me, "regular work hours" would not start before 9 or 10 o'clock, Saturday would not be a regular work day again, Sunday not at all, and i think in Sweden at least in parts four-day-work-weeks were at some time regular?, in Austria they disappear again where they existed. In any way, then this had to be rethought. Maybe different work times in winter? Schools in particular.) |Russia abolished clock changing, citing the medical issues: | |"President Dimitry Medvedev had made the decision to forgo daylight |savings earlier this year, citing a report the Russian Academy of |Medical Sciences. The report found that when the clocks are changed, |the number of heart attacks increases by 1.5 times and the rate of |suicides grows by 66 per cent." |<https://www.businessinsider.com/russia-clocks-daylight-saving-2011-10> Russia is a very large country, from the desert to the arctic, not to talk about the west-east distance. Of course population is not spread evenly, but nonetheless. And i personally am careful with anything that happened in between, say, 1990-2 to maybe 2007-10. They are still spending a lot of money to update run down houses and flats in large style, especially necessary still in the far east (what i think). But 'happy they can. (I myself of course am all in favour of wood, clay, and other such things, rather than concrete, but even in the rich west i am pretty lonely with that.) Not bad for a country that likely plunders itself rather than others! Whatever. You know, i cannot help it. I have not read the article you quote. Too different are the living conditions from eg Moscow, or a small village on the countryside, let alone some distant sibirian one. Or from an aerospace engineer to a bread factory worker to an alcoholic living in a communal appartment with shared kitchen and toilet, to a mother with four children of different age living in the same appartment. Interesting what they now do with Norilsk which Wikipedia claims to be the most dirty city in the world and such. On the country side, people there are still who need to consider in winter whether they go for fetching water into the cold, or stay in the kitchen with its wood-driven oven. This is a decision which takes time when you are an old woman. Look at her (it is an old photo, granted) https://en.wikipedia.org/wiki/File:Saint_Petersburg_woman_carrying_buckets_o... So may she finally discovered the heaven they all talk about. It was a hart live, and who knows how many then said to themselves that it is not worth the hazzle to go. I know many animals fly to the south, hectically try to eat as much as they can, .. give up .., _or_ die, in the fall. So you are saying, if i understood that correctly, that the additional impetus of a clock change increases that normal seasonal ... whatever it is? Well. That can be true. But then again live goes on. Humanity knows for many decades what will happen in this system, but nonetheless, the SUVs are getting bigger, the holidays are getting more expensive, the luxury of the western world is *IT* (for example the Fin who now heads Mercedes-Benz drops the small classes in 2025 even though they get sold like grazy, because luxury it is). We in fact started just another race with those dirty electrical cars, instead of spending a bit and waiting three or four more years, and then using those fuell cell cars that they talked about already in the 80s. No no, this is apples and oranges. Consciously we kill millions over millions, cause millions and millions of illnesses for smartphone production aka its resources all over the planet, and cause terrible living conditions, now or in a few years from now, with hundreds of millions loosing their home forever as the oceans rise. Let me please mention this bigotry. So in the end: i want to take into account the Russian condition by that time (it was getting better, luckily), and those many millions with an alcohol problem (and the alcohol quality, at times). So, in my opinion, any political decision that increases "light" -- again i want to recall that by the end of the 90s Russia could not even pay quite some pensions, and that many people luckily still had their datcha where they could grow food, too!, even in the early 00s many western companies plundering as they could (and they can)!, a lot of distortion there were!, i have just recently reread wonderful Peter Scholl-Latour's "Rußland im Zangengriff" ("cramped russia") from 2007, mind you!, heh!!, worth translating the Ukranian section alone!!!, HAH!!. It is not that i account only will to value people. I mean Princess Leia died while approaching Los Angeles airport of Trump-voted Unites States of America. With a heart attack! At that age! And her mother a day later. Now what are you going to do? Forbid Trump? No. (P.S.: the wonderful german singer Herbert Grönemeyer sang over 40 years ago "Amerika, prügel dich wenn du dich prügeln musst in deinem eigenen Land". Top modern. I think Trump knows this song. Bring the boys back home. So to say.) |I also remember reading a report that the dark mornings you get from |setting the clock forward causes higher rates of depression. And that |is the one thing I *do* care about with clocks in winter: I find it a |lot easier to wake up in the morning when we get daylight at 8:30 |compared to if we would get it at 9:30. I totally agree with you! (Though get into bed at around 5am in the morning, but i hate standing up and it is getting dark again already.) |(My brother-in-law in Tromsø of course does not have this problem at |all, the sun sets there next week, and will not rise again until |mid-January). Brave northern people. Mind you, i never ever have seen those northern lights in the sky. Luckily i am an idiot and do not know what it is. (Which reminds me of a maybe famous american quote, "they got twice --- all the sun!!!", whoever said that.) |\\// Peter - http://www.softwolves.pp.se/ I do not know whether that svedish virgin agrees with this classification. And Saab now also only remains as a weapon. :-( --End of <4e590c51-10ed-6aec-f82d-ef01b72ab704@softwolves.pp.se> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)