Meno Hochschild | 5 Mar 00:57 2015

[tz] historic Oslo times

Recently I noticed following strange detail of Europe/Oslo during the 
years 1940-1942:

The site reports for 
these years that Oslo kept summer time between 1940-08-10 23:00 and 
1942-11-02 03:00. But I cannot find a way in tz-data how to construct 
it. Maybe I have overlooked something.

Rule Norway 1916 only - May 22 1:00 1:00 S
Rule Norway 1916 only - Sep 30 0:00 0 -
Rule Norway 1945 only - Apr 2 2:00s 1:00 S
Rule Norway 1945 only - Oct 1 2:00s 0 -
Rule Norway 1959 1964 - Mar Sun>=15 2:00s 1:00 S
Rule Norway 1959 1965 - Sep Sun>=15 2:00s 0 -
Rule Norway 1965 only - Apr 25 2:00s 1:00 S

Zone    Europe/Oslo    0:43:00    -    LMT    1895 Jan 1
1:00 Norway CE%sT 1940 Aug 10 23:00
1:00 C-Eur CE%sT 1945 Apr 2 2:00
1:00 Norway CE%sT 1980
1:00 EU CE%sT

The Norway-rules do not catch the year 1940, so cannot indicate any 
summer time until 1940-08-10. Then the C-Eur-rule takes effect but see here:

Rule C-Eur 1940 only - Apr 1 2:00s 1:00 S
Rule C-Eur 1942 only - Nov 2 2:00s 0 -

The rule for 1940 cannot be applied because 1st of Apr is clearly before 
(Continue reading)

Juan Carlos YJ. Lin | 4 Mar 18:54 2015

[tz] Paraguay change DST 22/03/2015

Attending to Act  1.264, Paraguay change 4th sunday de March the DST, delay 1:00 hs

Juan Carlos Lin
Unisoft S.A.

System-wide Disclaimer---------------------------------------------------
"Antes de imprimir, recuC)rdese de su compromiso con el Medio Ambiente"
"Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisiC3n del contenido no estC! autorizada fuera del contexto de su envC-o y a quien corresponde. El uso no autorizado de la informaciC3n en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor bC3rrala y notifique al remitente en la brevedad posible. El contenido de es te mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias."

[tz] Idaho House Bill 198 proposing Year-Round DST "Won't Go Forward"

See chronology and details here:




Ray Harwood

Time Zone Report, a service of GoodClix, Inc. in the interest of public health and Twitter: <at> TimeZoneReport

Office: (480) 378-3221  -  Email: Ray <at>


Steffen Thorsen | 3 Mar 13:45 2015

[tz] Palestine DST postponed by a day

Sources such as and
say Palestine areas will start DST on 2015-03-28 00:00 which is one day 
later than

Our wrap-up:

As a side note, some sources report that Kuwait may introduce DST.
According to media reports like
the authorities are considering advancing clocks by 2 hours every year.

Best regards,
Steffen Thorsen -

Paul Eggert | 3 Mar 09:56 2015

[tz] [PATCH] * NEWS, Theory: Update info about Mars time, citing Chmielewski.

 NEWS   |  2 ++
 Theory | 10 +++++++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/NEWS b/NEWS
index dfda622..b6a306f 100644
--- a/NEWS
+++ b/NEWS
 <at>  <at>  -19,6 +19,8  <at>  <at>  Unreleased, experimental changes
     Cite the recent Mexican decree changing Quintana Roo's time zone.
     (Thanks to Carlos Raúl Perasso.)

+    Update info about Mars time.

 Release 2015a - 2015-01-29 22:35:20 -0800

diff --git a/Theory b/Theory
index e9be715..9861a4f 100644
--- a/Theory
+++ b/Theory
 <at>  <at>  -717,9 +717,11  <at>  <at>  Mittelalters und der Neuzeit_, herausgegeben von Dr. O. Grotefend

 ----- Time and time zones on Mars -----

-Some people have adjusted their work schedules to fit Mars time.
-Dozens of special Mars watches were built for Jet Propulsion
-Laboratory workers who kept Mars time during the Mars Exploration
+Some people's work schedules use Mars time.  Jet Propulsion Laboratory
+(JPL) coordinators have kept Mars time on and off at least since 1997
+for the Mars Pathfinder mission.  Some of their family members have
+also adapted to Mars time.  Dozens of special Mars watches were built
+for JPL workers who kept Mars time during the Mars Exploration
 Rovers mission (2004).  These timepieces look like normal Seikos and
 Citizens but use Mars seconds rather than terrestrial seconds.

 <at>  <at>  -760,6 +762,8  <at>  <at>  Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times
 (2004-01-14), pp A1, A20-A21.

+Tom Chmielewski, "Jet Lag Is Worse on Mars", The Atlantic (2015-02-26)

 Local Variables:


Glenn Eychaner | 24 Feb 13:13 2015

Re: [tz] Chilean time change

As far as I know, an official announcement of the adoption of a new time
change rule would have to appear in:
and would also appear in:
I have been monitoring both on a daily basis, and thus far have seen nothing.
So for now it's unclear to me whether this is a proposal or an announcement.


On Feb 24, 2015, at 9:00 AM, tz-request <at> wrote:

> I[s] this the announcement of the proposal or the announcement of the adoption of the proposal?

Glenn Eychaner (geychaner <at>
Telescope Systems Programmer, Las Campanas Observatory

Glenn Eychaner | 24 Feb 15:02 2015

Re: [tz] Chilean time change

As far as I know, an official announcement of the adoption of a new time
change rule would have to appear in:
and would also appear in:
I have been monitoring both on a daily basis, and thus far have seen nothing.
So for now it's unclear to me whether this is a proposal or an announcement.


On Feb 24, 2015, at 9:00 AM, tz-request <at> wrote:

> I[s] this the announcement of the proposal or the announcement of the adoption of the proposal?

Glenn Eychaner (geychaner <at>
Telescope Systems Programmer, Las Campanas Observatory

Nathan Justus | 16 Feb 15:47 2015

[tz] leap second insertions

>One additional second is all one needs, no?  Two leap seconds are never inserted adjacent to each other.  So
POSIX's 'struct timespec' suffices to >represent leap seconds, and there's no need for a new data type
here, just new operations on the type.  You could start by adding a new clock to >clock_gettime, a clock that
respects leap seconds.

There has never been more than one leap second added in any one instance, but as far as I know, nothing
precludes adding more than one at any one time.
But, I daresay there would be a really significant event that would cause it, such as an asteroid strike that
affect the day :)


Stuart Bishop | 16 Feb 13:35 2015

[tz] Chile/EasterIsland 1982 broken by 2015a?

My test suite broke with 2015a, leading me to Chile/EasterIsland and
Pacific/Easter in 1982:

Chile/EasterIsland  Sun Oct 11 04:00:00 1981 UT = Sat Oct 10 22:00:00
1981 EASST isdst=1 gmtoff=-21600
Chile/EasterIsland  Sat Mar 13 02:59:59 1982 UT = Fri Mar 12 20:59:59
1982 EASST isdst=1 gmtoff=-21600
Chile/EasterIsland  Sat Mar 13 03:00:00 1982 UT = Fri Mar 12 22:00:00
1982 EASST isdst=1 gmtoff=-18000
Chile/EasterIsland  Sun Mar 14 02:59:59 1982 UT = Sat Mar 13 21:59:59
1982 EASST isdst=1 gmtoff=-18000
Chile/EasterIsland  Sun Mar 14 03:00:00 1982 UT = Sat Mar 13 21:00:00
1982 EAST isdst=0 gmtoff=-21600
Chile/EasterIsland  Sun Oct 10 03:59:59 1982 UT = Sat Oct  9 21:59:59
1982 EAST isdst=0 gmtoff=-21600
Chile/EasterIsland  Sun Oct 10 04:00:00 1982 UT = Sat Oct  9 23:00:00
1982 EASST isdst=1 gmtoff=-18000
Chile/EasterIsland  Sun Mar 13 02:59:59 1983 UT = Sat Mar 12 21:59:59
1983 EASST isdst=1 gmtoff=-18000

Did it really put the clocks forward one hour on Mar 12, then back again Mar 13?


Stuart Bishop <stuart <at>>

random832 | 15 Feb 15:12 2015

[tz] An outline of a possible solution for sensible leap-second support.

Right now, very few people use the leap second support in tzcode. This
may represent a lack of demand, or it may be due to the fact that you
cannot have both leap second support and POSIX compliance at the same
time. Even when people do use it, it's often done in an incomplete and
incorrect way (e.g. by specifying the "right" folder directly in the TZ
variable). If the tz project intends to provide leap second support, I
would argue that it should be in a form that people can actually use.

Also, general question: is there any standard on how leap seconds are to
be handled in timezones that have an offset that is not a multiple of
one whole minute? What does tzcode do now?


Abandon entirely the time2posix/posix2time functions, the "right"
directory, and the notion of a time_t representation where e.g.
2000-01-01T00:00:00Z is represented by a value of 946684822 rather than
946684800. Very few people use them, and many of those who do use them
do so incorrectly even disregarding the issue of programs they may run
that do not call the conversion functions when they should. Remove
support for generating tzdata files with leap second data, and report an
error if one is loaded. 

Create a non-ambiguous representation for leap-aware timestamps. My
suggestion is a pair of {time_t time; int leap;}, with time being (for
leap seconds) the POSIX timestamp for the preceding normal second, and
leap=1 for s=60, leap=2 for s=61, etc.

Define a function interface which leap-aware systems may use to return
the correct time, with leap seconds and without any skew to attempt to
compensate for them. Tzcode to contain a dummy version that returns
{time, 0}. The value of the existing time() function around leap seconds
(e.g. whether it reports 23:59:59 twice, 00:00:00 twice, or implements
some form of skew over the course of the minute/hour/day) is
implementation-defined. (Arguably this new interface should also return
the best known correct time immediately rather than implementing skew in
the case of NTP adjustments as well, since unlike time() it is not
expected to be used by legacy programs as a pseudo-monotonic counter)

Define a file format and location (e.g. zoneinfo/leapdb) to store a
single copy of leap second information for use by the following

Define leap-aware interval-measurement (difftime) and interval-addition
(+ and - operator) functions. For example, since there was a leap second
in June 2012, difftime_l({1341100802, 0}, {1341100798, 0})
[2012-07-01T00:00:02Z minus 2012-06-30T23:59:58Z] is 5 rather than the
conventional 4. This is in contrast to the current implementation which
represents these times with different values that differ by 5, and
implements difftime by simple subtraction.

Define leap-aware versions of mktime_r, localtime_r, mktime_rz,
localtime_rz, gmtime_r, timegm_r, which use the new representation where
the normal ones use time_t.

Expanded scope (not part of tzcode/tzdata itself) - provide
recommendations of how to represent leap second times in filesystem
structures, archive structures, struct stat, struct timespec, and to
maintain backwards compatibility with existing ABIs which do not provide
this information (extending the range of an existing sub-second field is
worth considering in some cases, though 32-bit signed nanoseconds only
have room for one additional second in this way.)

J William Piggott | 12 Feb 22:56 2015

[tz] The zoneinfo file system tree structure ?

[please cc me, I am not subscribed]


I have been working on Util-linux' hwclock and other GNU/Linux date-time
issues. I have a couple of questions that I hope someone here can answer.

The tz database file system tree was changed on May 25 1998, moving
'right' and 'posix' from subdirectories of zoneinfo to sibling
directories. However GNU libc continued to use the old structure until
it stopped including the data files on Mar 7 2012. Now some Linux
distributions are still using the old subdirectory tree structure.

Is there a reason that the old tree structure is still being used?

Does it break something to have 'right' and 'posix' as sibling directories?

I ask because the problems that were the catalyst for the change in 1998
are still happening. It seems to me like it was a good solution, but
nobody used it.

If I may ask one more favor, could you please review the information
below which I have added to the hwclock man-page? I still need to
include information about using TZDIR.

Thank you very much,

       A discussion on date-time configuration  would  be  incomplete  without
       addressing  timezones,  this  is  mostly well covered by tzset(3).  One
       area that seems to have no documentation is the  'right'  directory  of
       the IANA Time Zone Database, aka tz, aka zoneinfo.

       There  are  two  separate  databases  in the zoneinfo system, posix and
       'right'. 'Right' (now named leaps) includes leap seconds and posix does
       not.  To  use  the  'right'  database  the System Clock must be kept in
       UTC + leap_seconds, i.e., TAI - 10. This allows calculating  the  exact
       number of seconds between two dates that cross a leap second epoch. The
       System Clock is then converted to the  correct  civil  time,  including
       UTC,  by  using the 'right' timezone files which subtract the leap sec-
       onds. Note: this configuration is considered experimental and is  known
       to have issues.

       To  configure  a  system  to use a particular database all of the files
       located  in  its  directory   must   be   copied   to   the   root   of
       /usr/share/zoneinfo.   Files  are never used directly from the posix or
       'right' subdirectories, e.g., TZ='right/Europe/Dublin'.  This habit was
       becoming  so common that the upstream zoneinfo project restructured the
       system's file tree by moving the posix and 'right'  subdirectories  out
       of the zoneinfo directory and into sibling directories:

       Unfortunately, some Linux distributions are changing it back to the old
       tree structure in their packages. So the problem of system  administra-
       tors  reaching  into the 'right' subdirectory persists. This causes the
       system timezone to be configured to  include  leap  seconds  while  the
       zoneinfo  database  is  still  configured to exclude them. Then when an
       application such as a World Clock needs the South_Pole  timezone  file;
       or  an email MTA, or hwclock needs the UTC timezone file; they fetch it
       from the root of /usr/share/zoneinfo , because that is  what  they  are
       supposed  to do. Those files exclude leap seconds, but the System Clock
       now includes them, causing an incorrect time conversion.

       Attempting to mix and match files from these  separate  databases  will
       not work, because they each require the System Clock to use a different
       timescale. The zoneinfo database must be configured to use either posix
       or 'right', as described above.