[tz] Time zone in Troll station

[Bengt-Inge Larsson]

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 at 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 at 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 at npolar.no Bengt-Inge Larsson <bengt-inge at 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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140204/4a74da10/attachment.html>

[Paul Eggert]

Post by Bengt-Inge Larsson
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 at 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.

[Paul-Inge Flakstad]

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 at npolar.no | [phone]

-----Original Message-----
From: Paul Eggert [mailto:eggert at cs.ucla.edu]
Sent: 8. mars 2014 08:19
To: Bengt-Inge Larsson; tz at iana.org
Cc: Paul-Inge Flakstad
Subject: Re: [tz] Time zone in Troll station

Post by Bengt-Inge Larsson
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 at 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.

[Paul Eggert]

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.
-------------- next part --------------
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule Troll 2005 max - Mar 1 1:00u 1:00 CET
Rule Troll 2005 max - Mar lastSun 1:00u 2:00 CEST
Rule Troll 2005 max - Oct lastSun 1:00u 1:00 CET
Rule Troll 2005 max - Nov 7 1:00u 0:00 UTC
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Antarctica/Troll 0 - zzz 2005 Feb 11
0:00 Troll %s

[Zefram]

Post by Paul Eggert
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]

Post by Zefram
zic should dynamically reallocate
its array as required, starting from a much smaller size.

Attached patch implements. I didn't touch localtime.c yet.

-zefram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zic_dynamic_times.patch
Type: text/x-diff
Size: 1580 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20140320/6e75d6bc/zic_dynamic_times.patch>

[Paul Eggert]

Post by Zefram
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.
-------------- next part --------------

[Philip Newton]

Post by Paul Eggert
Further comments welcome.

Patch 0002 introduces a typo: "ooverflow" (in zic.c, around line 400).

Cheers,
Philip

[Marc Lehmann]

Post by Paul Eggert
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.

[Paul Eggert]

Post by Marc Lehmann
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.

[Bengt-Inge Larsson]

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 at cs.ucla.edu>
Sent: Friday, March 21, 2014 4:12 AM
To: "Zefram" <zefram at fysh.org>
Cc: <tz at iana.org>; "Paul-Inge Flakstad" <flakstad at npolar.no>; "Bengt-Inge
Larsson" <bengt-inge at tele2.se>; "Arthur David Olson"
<arthurdavidolson at gmail.com>
Subject: Re: [tz] Troll throws zic for a loop

Post by Paul Eggert

Post by Zefram
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.

[Paul Eggert]

Post by Bengt-Inge Larsson
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.

-------------- next part --------------

[Christos Zoulas]

On Mar 20, 8:12pm, eggert at 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

[Paul Eggert]

[changing the subject line]

Post by Christos Zoulas
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?

[Christos Zoulas]

On Mar 21, 7:37am, eggert at 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

[Paul Eggert]

Post by Christos Zoulas
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

[Christos Zoulas]

On Mar 21, 9:04am, eggert at 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

[Paul Eggert]

Post by Christos Zoulas
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.

[Christos Zoulas]

On Mar 21, 9:17am, eggert at 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

[Christos Zoulas]

On Mar 21, 9:17am, eggert at 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

[Guy Harris]

Post by Christos Zoulas
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?)

[Alan Barrett]

On Mar 21, 2014, at 9:49 AM, christos at zoulas.com (Christos

Post by Christos Zoulas
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)

[Paul Eggert]

Post by Guy Harris
(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.

[Russ Allbery]

Post by Guy Harris

Post by Christos Zoulas
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.

[Christos Zoulas]

On Mar 21, 10:07am, guy at 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