Hello IANA! I have noticed that a number of research stations in Antarctica are listed in the tz database, but none in the UTC-1 to UTC+1 range, even if there should be such stations. One such station is the Troll station, which is operated year-around and belongs to Norway. I had a mail conversation with the responsible authority, the Norwegian Polar Institute, about which time zone the Troll station actually uses. The Troll station station officially uses UTC+0. During the dark season March-October, when no air or overland travel is done, it uses Norwegian summertime UTC+2 to simplify communication. So I suggest you add a new zone called Antarctica/Troll You may confirm this through Paul-Inge Flakstad at the Norwegian Polar Institute ( flakstad@npolar.no ) Yours Sincerely Bengt-Inge Larsson Sweden From: Paul-Inge Flakstad Sent: Monday, February 03, 2014 12:49 PM To: Bengt-Inge Larsson Cc: Nettredaktør Subject: RE: Time zone in Troll station Hi again Bengt-Inge, I can now confirm that Troll is indeed at UTC/GMT 0. Furthermore - should it be of interest to you - our overwintering team follow Norwegian time (including summer time) during the period they are alone at Troll (March-October). This practice is in place simply to make communication with the head office in Norway more convenient. Thank you for asking us about this. Questions like this and feedback in general are important factors in identifying weak spots in our information channels. In this case, we will update our website with more correct information about the Troll station. Best regards, Paul-Inge Flakstad From: Paul-Inge Flakstad Sent: 3. februar 2014 11:04 To: 'Bengt-Inge Larsson' Cc: Nettredaktør Subject: RE: Time zone in Troll station Hi again Bengt, I see now that my initial reply might have been misleading. Our website page about Troll (where I pulled the info from) states that "Troll is 2 hours after Norwegian time". With Norway in GMT +1, this would implicitly place Troll in GMT -1. However, I believe this is wrong, and that you are correct; Several reliable(ish) sources place Troll in GMT 0, and I assume they base this on geographical coordinates. This also fits nicely into the "2 hours behind"-info on our website, provided one is comparing to Norwegian summer time. I have sent an e-mail to our Antarctica department, asking for verification, and will come back to you with a definite answer as soon as I receive their reply. Best regards, Paul-Inge Flakstad From: Bengt-Inge Larsson [mailto:bengt-inge@tele2.se] Sent: 31. januar 2014 17:33 To: Paul-Inge Flakstad Subject: Re: Time zone in Troll station That has to be 2 hours behind Norwegian Summer time, because I see that the clock on the web camera photos are one hour behind the Central European Winter time. And some other source, unchecked reliability, says there is Greenwich Time in the Troll area. Or is it ? Bengt-Inge Larsson From: Paul-Inge Flakstad Sent: Wednesday, January 29, 2014 10:34 PM To: Nettredaktør ; Bengt-Inge Larsson Subject: SV: Time zone in Troll station Hi Bengt, Troll is 2 hours behind Norwegian time. Best regards,Paul-Inge FlakstadWeb developer, Norwegian Polar Instituteflakstad@npolar.no Bengt-Inge Larsson <bengt-inge@tele2.se>: Hello! Which time zone is kept at the Troll research station in Antarctica (what are the clocks there set at)? Or what is the time difference to Norway ? I ask since the time zone database used for computers contains some stations in Antarctica, only belonging to English speaking countries, USA; UK and Australia. But not Troll, and it seems that Troll is in some other time zone, since it is not located near those listed bases. Bengt Larsson Göteborg Sweden
Bengt-Inge Larsson wrote:
The Troll station station officially uses UTC+0. During the dark season March-October, when no air or overland travel is done, it uses Norwegian summertime UTC+2 to simplify communication. So I suggest you add a new zone called Antarctica/Troll
You may confirm this through Paul-Inge Flakstad at the Norwegian Polar Institute (flakstad@npolar.no )
Thanks for the heads-up. To create an entry we'll need some more-detailed information. Do they switch local clocks from UTC directly to UTC+2 regularly each year, or is the switchover irregular and informal? Likewise for the switch from UTC+2 back to UTC. For a tz entry we'll need exact switchover times. Is the official time (UTC) the time that people at the station normally use when coordinating with each other? When has the current station been inhabited? As I understand it, it was intended to be year-round but has been closed some winters. Thanks.
Hi Paul and Bengt-Inge, Troll was established in 1989/90, and was originally a summer station. However, this changed in 2005, when Troll was re-opened as a year-round station. At the same time, Troll Airfield was also officially opened. About the time zone at Troll: UTC+1/UTC+2: (This is Norwegian time, with UTC+2 being DST.) The Norwegian Polar Institute’s overwintering team at Troll follow Norwegian time during the Antarctic winter season (typically March–October, inclusive). During this period they are alone at Troll, and the practice of using Norwegian time is in place simply to make communication with the head office in Norway more convenient. UTC+0: During the Antarctic summer season (the "busy" season). The exact switch dates will vary along with when the winter season starts and ends. Typically the winter season spans from the last week of February to the first week of November – but note that “typically” is the key word here; Weather conditions and other circumstances make it practically impossible for us to have any specific dates carved in stone. I recently had a long dialog about this with the developer of timegenie.com. In the absence of specific dates, he decided to choose some likely ones: GMT +1 — From March 1 to the last Sunday in March GMT +2 — From the last Sunday in March until the last Sunday in October GMT +1 — From the last Sunday in October until November 7 GMT +0 — From November 7 until March 1 The dates for switching to and from UTC+0 will probably not be absolutely correct, but they should be quite close to the actual dates. I hope this answered your questions. Please don't hesitate to contact me again if there is need for further clarification. Best regards, Paul-Inge Flakstad Web developer, Norwegian Polar Institute flakstad@npolar.no | +47 777 50 639 -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: 8. mars 2014 08:19 To: Bengt-Inge Larsson; tz@iana.org Cc: Paul-Inge Flakstad Subject: Re: [tz] Time zone in Troll station Bengt-Inge Larsson wrote:
The Troll station station officially uses UTC+0. During the dark season March-October, when no air or overland travel is done, it uses Norwegian summertime UTC+2 to simplify communication. So I suggest you add a new zone called Antarctica/Troll
You may confirm this through Paul-Inge Flakstad at the Norwegian Polar Institute (flakstad@npolar.no )
Thanks for the heads-up. To create an entry we'll need some more-detailed information. Do they switch local clocks from UTC directly to UTC+2 regularly each year, or is the switchover irregular and informal? Likewise for the switch from UTC+2 back to UTC. For a tz entry we'll need exact switchover times. Is the official time (UTC) the time that people at the station normally use when coordinating with each other? When has the current station been inhabited? As I understand it, it was intended to be year-round but has been closed some winters. Thanks.
Thanks for the Troll station info <http://mm.icann.org/pipermail/tz/2014-March/020705.html>. Unfortunately, when I tried to encode Troll's unusual timekeeping practices into standard tz data format (see attached file), the shell command "zic test.tzi" complained '"test.tzi", line 8: too many transitions?! (rule from "test.tzi", line 2)'. I guess this is some sort of limitation in either zic or the tz binary file format. I hope Arthur David Olson can find some free time to look into it.
Paul Eggert wrote:
complained '"test.tzi", line 8: too many transitions?! (rule from "test.tzi", line 2)'. I guess this is some sort of limitation in either zic or the tz binary file format.
It's zic. The four-transitions-per-year pattern can't be represented as a POSIXish-TZ value, so the 400-year hack applies. That requires writing out somewhat over 1600 explicit transitions. The tzfile format has no problem with this, but zic uses a statically-allocated array of 1200 elements to accumulate the transitions during compilation. Once that array is full, you get the error message. The quick fix is to bump 1200 (TZ_MAX_TIMES in tzfile.h) up to 2000. But it's a fundamentally flawed system. zic should dynamically reallocate its array as required, starting from a much smaller size. The same goes for localtime.c, which uses the same transition limit. Existing Olson localtime.c won't be able to use the Troll tzfile once it's generated by a more capable zic. Other tzfile parsers will vary in their ability to handle it. Just one more data point: glibc's tzfile parser dynamically allocates space and so should handle the Troll tzfile just fine. -zefram
Zefram wrote:
Attached patch implements. I didn't touch localtime.c yet.
Thanks for looking into it; that helps quite a bit. I'm reluctant to have localtime.c invoke malloc, since that'd be a new way for localtime to fail; it's purposely designed to not malloc unless the builder #defines ALL_STATE. If mad scientists in Antarctica keep cooking up new ways to tell time we may have to do something more drastic, but for now bumping TZ_MAX_TIMES a bit should be a relatively painless way forward. The new Antarctica/Troll entry would be rejected by current 'zic' implementations, so it may be prudent to comment it out at first, and let the new 'zic' propagate for a bit, before uncommenting it in a later relese. As you mention, if Antarctica/Troll is built by a new 'zic', GNU/Linux will operate correctly on it but 2014a-or-earlier localtime will silently treat it as if it were UTC. I have verified that Solaris 11 localtime has similar problems, and I expect other implementations will too. As the issue is limited to one small station in Antarctica I suppose it's not a big deal. For now I installed the attached patches to the experimental version on github. These should fix the bugs mentioned in this area, along with some further gotchas that I noticed will reviewing and improving the patches. Further comments welcome.
I would like to suggest not commenting out Antarctica/Troll, but for the time being have it as UTC+0 only, or UTC+0 during European winter time and UTC+2 during European summer time. I suggested adding Troll as representing Antarctic stations near zero longitude, as there were none before. Better than nothing. Bengt-Inge Larsson -------------------------------------------------- From: "Paul Eggert" <eggert@cs.ucla.edu> Sent: Friday, March 21, 2014 4:12 AM To: "Zefram" <zefram@fysh.org> Cc: <tz@iana.org>; "Paul-Inge Flakstad" <flakstad@npolar.no>; "Bengt-Inge Larsson" <bengt-inge@tele2.se>; "Arthur David Olson" <arthurdavidolson@gmail.com> Subject: Re: [tz] Troll throws zic for a loop
Zefram wrote:
Attached patch implements. I didn't touch localtime.c yet.
Thanks for looking into it; that helps quite a bit.
I'm reluctant to have localtime.c invoke malloc, since that'd be a new way for localtime to fail; it's purposely designed to not malloc unless the builder #defines ALL_STATE. If mad scientists in Antarctica keep cooking up new ways to tell time we may have to do something more drastic, but for now bumping TZ_MAX_TIMES a bit should be a relatively painless way forward.
The new Antarctica/Troll entry would be rejected by current 'zic' implementations, so it may be prudent to comment it out at first, and let the new 'zic' propagate for a bit, before uncommenting it in a later relese.
As you mention, if Antarctica/Troll is built by a new 'zic', GNU/Linux will operate correctly on it but 2014a-or-earlier localtime will silently treat it as if it were UTC. I have verified that Solaris 11 localtime has similar problems, and I expect other implementations will too. As the issue is limited to one small station in Antarctica I suppose it's not a big deal.
For now I installed the attached patches to the experimental version on github. These should fix the bugs mentioned in this area, along with some further gotchas that I noticed will reviewing and improving the patches. Further comments welcome.
Bengt-Inge Larsson wrote:
I would like to suggest not commenting out Antarctica/Troll, but for the time being have it as UTC+0 only, or UTC+0 during European winter time and UTC+2 during European summer time.
Thanks, good idea. I pushed the attached patch to the experimental repository to do the latter.
On Thu, Mar 20, 2014 at 08:12:15PM -0700, Paul Eggert <eggert@cs.ucla.edu> wrote:
I'm reluctant to have localtime.c invoke malloc, since that'd be a new way for localtime to fail; it's purposely designed to not malloc unless the builder #defines ALL_STATE. If mad scientists in
If the number of transitions in the table is ultimately bounded (which seems to be the case here), then not using malloc is safer, faster, simpler, more memory efficient, and cleaner for zic. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_,_/ /_/\_\
Marc Lehmann wrote:
If the number of transitions in the table is ultimately bounded (which seems to be the case here), then not using malloc is safer, faster, simpler, more memory efficient, and cleaner for zic.
Having zic avoid malloc is less resilient in the face of future changes, such as the ones needed for Troll. If zic had already been using malloc, we could ship the new Antarctica/Troll now, without worrying about old zic implementations rejecting it. If zic starts using malloc now, future changes like this should be easier to deploy. Plus, zic is already using malloc elsewhere, so using malloc for these cases doesn't introduce any fundamental new problems. malloc is more problematic for localtime, not just in terms of runtime overhead, but in terms of safety and correctness: there are applications where it's not nice to display the time incorrectly (or not at all -- or worse, dump core) merely because malloc failed. There are embedded environments where use of malloc is frowned upon entirely, for these reasons. These considerations generally don't apply to zic, which makes it more reasonable to use malloc in zic than in localtime.
On Mar 20, 8:12pm, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: Re: [tz] Troll throws zic for a loop | I'm reluctant to have localtime.c invoke malloc, since that'd be a new | way for localtime to fail; it's purposely designed to not malloc unless | the builder #defines ALL_STATE. If mad scientists in Antarctica keep | cooking up new ways to tell time we may have to do something more | drastic, but for now bumping TZ_MAX_TIMES a bit should be a relatively | painless way forward. This ship has already sailed. It is not like the mad scientists in Antarctica still run on 8 bit microprocessors any more. Let's move on. Most of the world is running on multicore processors who want a tzlib that is thread safe, and does not require mutexes to work. Can we move in that direction please? christos
[changing the subject line] Christos Zoulas wrote:
Most of the world is running on multicore processors who want a tzlib that is thread safe, and does not require mutexes to work. Can we move in that direction please?
We could add that to our list of things to do. Is a public-domain implementation available?
On Mar 21, 7:37am, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: thread-safe localtime | [changing the subject line] | | Christos Zoulas wrote: | > Most of the world is running on multicore processors who want a tzlib | > that is thread safe, and does not require mutexes to work. Can we move | > in that direction please? | | We could add that to our list of things to do. Is a public-domain | implementation available? The NetBSD one (using the timezone_t stuff I proposed years ago), except for gmtime() which I have not fixed yet. christos
Christos Zoulas wrote:
The NetBSD one
As I understand it, NetBSD is not public domain. Is there an exception for its timezone-related code? http://www.netbsd.org/about/redistribution.html
On Mar 21, 9:04am, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: Re: thread-safe localtime | Christos Zoulas wrote: | > The NetBSD one | | As I understand it, NetBSD is not public domain. Is there an exception | for its timezone-related code? I wrote the code and I donate it if that matters, but what's more important is that the license on those files is the same as the original tz files since the differences are minor. christos
Christos Zoulas wrote:
I wrote the code and I donate it if that matters, but what's more important is that the license on those files is the same as the original tz files since the differences are minor.
Ah, OK, thanks. localtime.c is public-domain, but strftime.c and date.c are BSD-licensed. The important changes here are to localtime.c; if you donate all your changes to the public domain, we can merge them into localtime.c (strftime.c is just the icing on the cake). So that should address the legal concerns, though there still is the technical problem of actually doing the merge.
On Mar 21, 9:17am, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: Re: thread-safe localtime | Christos Zoulas wrote: | > I wrote the code and I donate it if that matters, but what's more important | > is that the license on those files is the same as the original tz files since | > the differences are minor. | | Ah, OK, thanks. localtime.c is public-domain, but strftime.c and date.c | are BSD-licensed. The important changes here are to localtime.c; if you | donate all your changes to the public domain, we can merge them into | localtime.c (strftime.c is just the icing on the cake). So that should | address the legal concerns, though there still is the technical problem | of actually doing the merge. I donate all my changes to the public domain. Yes, I agree the merge is the biggest issue. I wish it was easier... christos
On Mar 21, 9:17am, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: Re: thread-safe localtime I forgot to mention, that adopting the manual pages would be nice too, since they are in mdoc instead of man format which is much nicer. christos
On Mar 21, 2014, at 9:49 AM, christos@zoulas.com (Christos Zoulas) wrote:
I forgot to mention, that adopting the manual pages would be nice too, since they are in mdoc instead of man format which is much nicer.
It's nicer, but is it as widely supported on the various UN*Xes that have adopted the tz code? It's supported on *BSD and OS X, and might be supported on at least some Linux distributions, but is it supported on, for example, Solaris? (Or are all the Solaris man pages in SGML these days, so Oracle would have to rewrite the man pages anyway?)
On Fri, 21 Mar 2014, Guy Harris wrote:
On Mar 21, 2014, at 9:49 AM, christos@zoulas.com (Christos Zoulas) wrote:
I forgot to mention, that adopting the manual pages would be nice too, since they are in mdoc instead of man format which is much nicer.
It's nicer, but is it as widely supported on the various UN*Xes that have adopted the tz code?
It would be possible to distribute both mdoc and old-style man versions of the manual pages, with the mdoc versions being the masters, and the man versions being generated at distribution time. Then downstream projects could choose which version to use. I am aware of two ways of converting from mdoc to man: mandoc (previously known as mdocml, and available from <http://mdocml.bsd.lv>), and mdoc2man.awk (which I think was once distributed with OpenSSH). --apb (Alan Barrett)
On 03/21/2014 10:07 AM, Guy Harris wrote:
(Or are all the Solaris man pages in SGML these days, so Oracle would have to rewrite the man pages anyway?) Solaris 11 man pages are almost all in troff form, not SGML. Solaris 11 doesn't ship with -mdoc; it still uses good old -man.
On Mar 21, 10:07am, guy@alum.mit.edu (Guy Harris) wrote: -- Subject: Re: [tz] thread-safe localtime | It's nicer, but is it as widely supported on the various UN*Xes that have a= | dopted the tz code? It's supported on *BSD and OS X, and might be supporte= | d on at least some Linux distributions, but is it supported on, for example= | , Solaris? (Or are all the Solaris man pages in SGML these days, so Oracle= | would have to rewrite the man pages anyway?) I don't know. I would guess that Oracle will prefer mdoc in that case since it is a lot simpler to convert to SGML since it is a semantic markup as opposed to a formatting one. Perhaps people on this list who have OS's that have "man" only pages can chime in? I don't think it is a big barrier though given that there are BSD licensed "mdoc" macros and tzcode supplies pre-formatted pages anyway... christos
Guy Harris <guy@alum.mit.edu> writes:
On Mar 21, 2014, at 9:49 AM, christos@zoulas.com (Christos Zoulas) wrote:
I forgot to mention, that adopting the manual pages would be nice too, since they are in mdoc instead of man format which is much nicer.
It's nicer, but is it as widely supported on the various UN*Xes that have adopted the tz code? It's supported on *BSD and OS X, and might be supported on at least some Linux distributions, but is it supported on, for example, Solaris?
I'm 95% sure that mdoc is supported on all Linux distributions, since I believe all Linux distributions are using groff as the *roff formatter, and groff has supported mdoc for basically forever. -- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>
participants (10)
-
Alan Barrett -
Bengt-Inge Larsson -
christos＠zoulas.com -
Guy Harris -
Marc Lehmann -
Paul Eggert -
Paul-Inge Flakstad -
Philip Newton -
Russ Allbery -
Zefram