1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
  
25
  
26
  
27
  
28
  
29
  
30
  
31
  
32
  
33
  
34
  
35
  
36
  
37
  
38
  
39
  
40
  
41
  
42
  
43
  
44
  
45
  
46
  
47
  
48
  
49
  
50
  
51
  
52
  
53
  
54
  
55
  
56
  
57
  
58
  
59
  
60
  
61
  
62
  
63
  
64
  
65
  
66
  
67
  
68
  
69
  
70
  
71
  
72
  
73
  
74
  
75
  
76
  
77
  
78
  
79
  
80
  
81
  
82
  
83
  
84
  
85
  
86
  
87
  
88
  
89
  
90
  
91
  
92
  
93
  
94
  
95
  
96
  
97
  
98
  
99
  
100
  
101
  
102
  
103
  
104
  
105
  
106
  
107
  
108
  
109
  
110
  
111
  
112
  
113
  
114
  
115
  
116
  
117
  
118
  
119
  
120
  
121
  
122
  
123
  
124
  
125
  
126
  
127
  
128
  
129
  
130
  
131
  
132
  
133
  
134
  
135
  
136
  
137
  
138
  
139
  
140
  
141
  
142
  
143
  
144
  
145
  
146
  
147
  
148
  
149
  
150
  
151
  
152
  
153
  
154
  
155
  
156
  
157
  
158
  
159
  
160
  
161
  
162
  
163
  
164
  
165
  
166
  
167
  
168
  
169
  
170
  
171
  
172
  
173
  
174
  
175
  
176
  
177
  
178
  
179
  
180
  
181
  
182
  
183
  
184
  
185
  
186
  
187
  
188
  
189
  
190
  
191
  
192
  
193
  
194
  
195
  
196
  
197
  
198
  
199
  
200
  
201
  
202
  
203
  
204
  
205
  
206
  
207
  
208
  
209
  
210
  
211
  
212
  
213
  
214
  
215
  
216
  
217
  
218
  
219
  
220
  
221
  
222
  
223
  
224
  
225
  
226
  
227
  
228
  
229
  
230
  
231
  
232
  
233
  
234
  
235
  
236
  
237
  
238
  
239
  
240
  
241
  
242
  
243
  
244
  
245
  
246
  
247
  
248
  
249
  
250
  
251
  
252
  
253
  
254
  
255
  
256
  
257
  
258
  
259
  
260
  
261
  
262
  
263
  
264
  
265
  
266
  
267
  
268
  
269
  
270
  
271
  
272
  
273
  
274
  
275
  
276
  
277
  
278
  
279
  
280
  
281
  
282
  
283
  
284
  
285
  
286
  
287
  
288
  
289
  
290
  
291
  
292
  
293
  
294
  
295
  
296
  
297
  
298
  
299
  
300
  
301
  
302
  
303
  
304
  
305
  
306
  
307
  
308
  
309
  
310
  
311
  
312
  
313
  
314
  
315
  
316
  
317
  
318
  
319
  
320
  
321
  
322
  
323
  
324
  
325
  
326
  
327
  
328
  
329
  
330
  
331
  
332
  
333
  
334
  
335
  
336
  
337
  
338
  
339
  
340
  
341
  
342
  
343
  
344
  
345
  
346
  
347
  
348
  
349
  
350
  
351
  
352
  
353
  
354
  
355
  
356
  
357
  
358
  
359
  
360
  
361
  
362
  
363
  
364
  
365
  
366
  
367
  
368
  
369
  
370
  
371
  
372
  
373
  
374
  
375
  
376
  
377
  
378
  
379
  
380
  
381
  
382
  
383
  
384
  
385
  
386
  
387
  
388
  
389
  
390
  
391
  
392
  
393
  
394
  
395
  
396
  
397
  
398
  
399
  
400
  
401
  
402
  
403
  
404
  
405
  
406
  
407
  
408
  
409
  
410
  
411
  
412
  
413
  
414
  
415
  
416
  
417
  
418
  
419
  
420
  
421
  
422
  
423
  
424
  
425
  
426
  
427
  
428
  
429
  
430
  
431
  
432
  
433
  
434
  
435
  
436
  
437
  
438
  
439
  
440
  
441
  
442
  
443
  
444
  
445
  
446
  
447
  
448
  
449
  
450
  
451
  
452
  
453
  
454
  
455
  
456
  
457
  
458
  
459
  
460
  
461
  
462
  
463
  
464
  
465
  
466
  
467
  
468
  
469
  
470
  
471
  
472
  
473
  
474
  
475
  
476
  
477
  
478
  
479
  
480
  
481
  
482
  
483
  
484
  
485
  
486
  
487
  
488
  
489
  
490
  
491
  
492
  
493
  
494
  
495
  
496
  
497
  
498
  
499
  
500
  
501
  
502
  
503
  
504
  
505
  
506
  
507
  
508
  
509
  
510
  
511
  
512
  
513
  
514
  
515
  
516
  
517
  
518
  
519
  
520
  
521
  
522
  
523
  
524
  
525
  
526
  
527
  
528
  
529
  
530
  
531
  
532
  
533
  
534
  
535
  
536
  
537
  
538
  
539
  
540
  
541
  
542
  
543
  
544
  
545
  
546
  
547
  
548
  
549
  
550
  
551
  
552
  
553
  
554
  
555
  
556
  
557
  
558
  
559
  
560
  
561
  
562
  
563
  
564
  
565
  
566
  
567
  
568
  
569
  
570
  
571
  
572
  
573
  
574
  
575
  
576
  
577
  
578
  
579
  
580
  
581
  
582
  
583
  
584
  
585
  
586
  
587
  
588
  
589
  
590
  
591
  
592
  
593
  
594
  
595
  
596
  
597
  
598
  
599
  
600
  
601
  
602
  
603
  
604
  
605
  
606
  
607
  
608
  
609
  
610
  
611
  
612
  
613
  
614
  
615
  
616
  
617
  
618
  
619
  
620
  
621
  
622
  
623
  
624
  
625
  
626
  
627
  
628
  
629
  
630
  
631
  
632
  
633
  
634
  
635
  
636
  
637
  
638
  
639
  
640
  
641
  
642
  
643
  
644
  
645
  
646
  
647
  
648
  
649
  
650
  
651
  
652
  
653
  
654
  
655
  
656
  
657
  
658
  
659
  
660
  
661
  
662
  
663
  
664
  
665
  
666
  
667
  
668
  
669
  
670
  
671
  
672
  
673
  
674
  
675
  
676
  
677
  
678
  
679
  
680
  
681
  
682
  
683
  
684
  
685
  
686
  
687
  
688
  
689
  
690
  
691
  
692
  
693
  
694
  
695
  
696
  
697
  
698
  
699
  
700
  
701
  
702
  
703
  
704
  
705
  
706
  
707
  
708
  
709
  
710
  
711
  
712
  
713
  
714
  
715
  
716
  
717
  
718
  
719
  
720
  
721
  
722
  
723
  
724
  
725
  
726
  
727
  
728
  
729
  
730
  
731
  
732
  
733
  
734
  
735
  
736
  
737
  
738
  
739
  
740
  
741
  
742
  
743
  
744
  
745
  
746
  
747
  
748
  
749
  
750
  
751
  
752
  
753
  
754
  
755
  
756
  
757
  
758
  
759
  
760
  
761
  
762
  
763
  
764
  
765
  
766
  
767
  
768
  
This file is in the public domain, so clarified as of 
2009-05-17 by Arthur David Olson. 
 
----- Outline ----- 
 
        Time and date functions 
        Scope of the tz database 
        Names of time zone rule files 
        Time zone abbreviations 
        Calendrical issues 
        Time and time zones on Mars 
 
----- Time and date functions ----- 
 
These time and date functions are upwards compatible with those of POSIX, 
an international standard for UNIX-like systems. 
As of this writing, the current edition of POSIX is: 
 
  The Open Group Base Specifications Issue 7 
  IEEE Std 1003.1, 2013 Edition 
  <http://pubs.opengroup.org/onlinepubs/9699919799/> 
 
POSIX has the following properties and limitations. 
 
*       In POSIX, time display in a process is controlled by the 
        environment variable TZ.  Unfortunately, the POSIX TZ string takes 
        a form that is hard to describe and is error-prone in practice. 
        Also, POSIX TZ strings can't deal with other (for example, Israeli) 
        daylight saving time rules, or situations where more than two 
        time zone abbreviations are used in an area. 
 
        The POSIX TZ string takes the following form: 
 
                stdoffset[dst[offset][,date[/time],date[/time]]] 
 
        where: 
 
        std and dst 
                are 3 or more characters specifying the standard 
                and daylight saving time (DST) zone names. 
                Starting with POSIX.1-2001, std and dst may also be 
                in a quoted form like "<UTC+10>"; this allows 
                "+" and "-" in the names. 
        offset 
                is of the form '[+-]hh:[mm[:ss]]' and specifies the 
                offset west of UT.  'hh' may be a single digit; 0<=hh<=24. 
                The default DST offset is one hour ahead of standard time. 
        date[/time],date[/time] 
                specifies the beginning and end of DST.  If this is absent, 
                the system supplies its own rules for DST, and these can 
                differ from year to year; typically US DST rules are used. 
        time 
                takes the form 'hh:[mm[:ss]]' and defaults to 02:00. 
                This is the same format as the offset, except that a 
                leading '+' or '-' is not allowed. 
        date 
                takes one of the following forms: 
                Jn (1<=n<=365) 
                        origin-1 day number not counting February 29 
                n (0<=n<=365) 
                        origin-0 day number counting February 29 if present 
                Mm.n.d (0[Sunday]<=d<=6[Saturday], 1<=n<=5, 1<=m<=12) 
                        for the dth day of week n of month m of the year, 
                        where week 1 is the first week in which day d appears, 
                        and '5' stands for the last week in which day d appears 
                        (which may be either the 4th or 5th week). 
                        Typically, this is the only useful form; 
                        the n and Jn forms are rarely used. 
 
        Here is an example POSIX TZ string, for US Pacific time using rules 
        appropriate from 1987 through 2006: 
 
                TZ='PST8PDT,M4.1.0/02:00,M10.5.0/02:00' 
 
        This POSIX TZ string is hard to remember, and mishandles time stamps 
        before 1987 and after 2006.  With this package you can use this 
        instead: 
 
                TZ='America/Los_Angeles' 
 
*       POSIX does not define the exact meaning of TZ values like "EST5EDT". 
        Typically the current US DST rules are used to interpret such values, 
        but this means that the US DST rules are compiled into each program 
        that does time conversion.  This means that when US time conversion 
        rules change (as in the United States in 1987), all programs that 
        do time conversion must be recompiled to ensure proper results. 
 
*       In POSIX, there's no tamper-proof way for a process to learn the 
        system's best idea of local wall clock.  (This is important for 
        applications that an administrator wants used only at certain times - 
        without regard to whether the user has fiddled the "TZ" environment 
        variable.  While an administrator can "do everything in UTC" to get 
        around the problem, doing so is inconvenient and precludes handling 
        daylight saving time shifts - as might be required to limit phone 
        calls to off-peak hours.) 
 
*       POSIX requires that systems ignore leap seconds. 
 
*       The tz code attempts to support all the time_t implementations 
        allowed by POSIX.  The time_t type represents a nonnegative count of 
        seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds. 
        In practice, time_t is usually a signed 64- or 32-bit integer; 32-bit 
        signed time_t values stop working after 2038-01-19 03:14:07 UTC, so 
        new implementations these days typically use a signed 64-bit integer. 
        Unsigned 32-bit integers are used on one or two platforms, 
        and 36-bit integers are also used occasionally. 
        Although earlier POSIX versions allowed time_t to be a 
        floating-point type, this was not supported by any practical 
        systems, and POSIX.1-2013 and the tz code both require time_t 
        to be an integer type. 
 
These are the extensions that have been made to the POSIX functions: 
 
*       The "TZ" environment variable is used in generating the name of a file 
        from which time zone information is read (or is interpreted a la 
        POSIX); "TZ" is no longer constrained to be a three-letter time zone 
        name followed by a number of hours and an optional three-letter 
        daylight time zone name.  The daylight saving time rules to be used 
        for a particular time zone are encoded in the time zone file; 
        the format of the file allows U.S., Australian, and other rules to be 
        encoded, and allows for situations where more than two time zone 
        abbreviations are used. 
 
        It was recognized that allowing the "TZ" environment variable to 
        take on values such as "America/New_York" might cause "old" programs 
        (that expect "TZ" to have a certain form) to operate incorrectly; 
        consideration was given to using some other environment variable 
        (for example, "TIMEZONE") to hold the string used to generate the 
        time zone information file name.  In the end, however, it was decided 
        to continue using "TZ": it is widely used for time zone purposes; 
        separately maintaining both "TZ" and "TIMEZONE" seemed a nuisance; 
        and systems where "new" forms of "TZ" might cause problems can simply 
        use TZ values such as "EST5EDT" which can be used both by 
        "new" programs (a la POSIX) and "old" programs (as zone names and 
        offsets). 
 
*       To handle places where more than two time zone abbreviations are used, 
        the functions "localtime" and "gmtime" set tzname[tmp->tm_isdst] 
        (where "tmp" is the value the function returns) to the time zone 
        abbreviation to be used.  This differs from POSIX, where the elements 
        of tzname are only changed as a result of calls to tzset. 
 
*       Since the "TZ" environment variable can now be used to control time 
        conversion, the "daylight" and "timezone" variables are no longer 
        needed.  (These variables are defined and set by "tzset"; however, their 
        values will not be used by "localtime.") 
 
*       The "localtime" function has been set up to deliver correct results 
        for near-minimum or near-maximum time_t values.  (A comment in the 
        source code tells how to get compatibly wrong results). 
 
*       A function "tzsetwall" has been added to arrange for the system's 
        best approximation to local wall clock time to be delivered by 
        subsequent calls to "localtime."  Source code for portable 
        applications that "must" run on local wall clock time should call 
        "tzsetwall();" if such code is moved to "old" systems that don't 
        provide tzsetwall, you won't be able to generate an executable program. 
        (These time zone functions also arrange for local wall clock time to be 
        used if tzset is called - directly or indirectly - and there's no "TZ" 
        environment variable; portable applications should not, however, rely 
        on this behavior since it's not the way SVR2 systems behave.) 
 
*       Negative time_t values are supported, on systems where time_t is signed. 
 
*       These functions can account for leap seconds, thanks to Bradley White. 
 
Points of interest to folks with other systems: 
 
*       This package is already part of many POSIX-compliant hosts, 
        including BSD, HP, Linux, Network Appliance, SCO, SGI, and Sun. 
        On such hosts, the primary use of this package 
        is to update obsolete time zone rule tables. 
        To do this, you may need to compile the time zone compiler 
        'zic' supplied with this package instead of using the system 'zic', 
        since the format of zic's input changed slightly in late 1994, 
        and many vendors still do not support the new input format. 
 
*       The UNIX Version 7 "timezone" function is not present in this package; 
        it's impossible to reliably map timezone's arguments (a "minutes west 
        of GMT" value and a "daylight saving time in effect" flag) to a 
        time zone abbreviation, and we refuse to guess. 
        Programs that in the past used the timezone function may now examine 
        tzname[localtime(&clock)->tm_isdst] to learn the correct time 
        zone abbreviation to use.  Alternatively, use 
        localtime(&clock)->tm_zone if this has been enabled. 
 
*       The 4.2BSD gettimeofday function is not used in this package. 
        This formerly let users obtain the current UTC offset and DST flag, 
        but this functionality was removed in later versions of BSD. 
 
*       In SVR2, time conversion fails for near-minimum or near-maximum 
        time_t values when doing conversions for places that don't use UT. 
        This package takes care to do these conversions correctly. 
 
The functions that are conditionally compiled if STD_INSPIRED is defined 
should, at this point, be looked on primarily as food for thought.  They are 
not in any sense "standard compatible" - some are not, in fact, specified in 
*any* standard.  They do, however, represent responses of various authors to 
standardization proposals. 
 
Other time conversion proposals, in particular the one developed by folks at 
Hewlett Packard, offer a wider selection of functions that provide capabilities 
beyond those provided here.  The absence of such functions from this package 
is not meant to discourage the development, standardization, or use of such 
functions.  Rather, their absence reflects the decision to make this package 
contain valid extensions to POSIX, to ensure its broad acceptability.  If 
more powerful time conversion functions can be standardized, so much the 
better. 
 
 
----- Scope of the tz database ----- 
 
The tz database attempts to record the history and predicted future of 
all computer-based clocks that track civil time.  To represent this 
data, the world is partitioned into regions whose clocks all agree 
about time stamps that occur after the somewhat-arbitrary cutoff point 
of the POSIX Epoch (1970-01-01 00:00:00 UTC).  For each such region, 
the database records all known clock transitions, and labels the region 
with a notable location.  Although 1970 is a somewhat-arbitrary 
cutoff, there are significant challenges to moving the cutoff earlier 
even by a decade or two, due to the wide variety of local practices 
before computer timekeeping became prevalent. 
 
Clock transitions before 1970 are recorded for each such location, 
because most POSIX-compatible systems support negative time stamps and 
could misbehave if data entries were omitted for pre-1970 transitions. 
However, the database is not designed for and does not suffice for 
applications requiring accurate handling of all past times everywhere, 
as it would take far too much effort and guesswork to record all 
details of pre-1970 civil timekeeping. 
 
 
----- Accuracy of the tz database ----- 
 
The tz database is not authoritative, and it surely has errors. 
Corrections are welcome and encouraged; see the file CONTRIBUTING. 
Users requiring authoritative data should consult national standards 
bodies and the references cited in the database's comments. 
 
Errors in the tz database arise from many sources: 
 
 * The tz database predicts future time stamps, and current predictions 
   will be incorrect after future governments change the rules. 
   For example, if today someone schedules a meeting for 13:00 next 
   October 1, Casablanca time, and tomorrow Morocco changes its 
   daylight saving rules, software can mess up after the rule change 
   if it blithely relies on conversions made before the change. 
 
 * The pre-1970 entries in this database cover only a tiny sliver of how 
   clocks actually behaved; the vast majority of the necessary 
   information was lost or never recorded.  Thousands more zones would 
   be needed if the tz database's scope were extended to cover even 
   just the known or guessed history of standard time; for example, 
   the current single entry for France would need to split into dozens 
   of entries, perhaps hundreds. 
 
 * Most of the pre-1970 data entries come from unreliable sources, often 
   astrology books that lack citations and whose compilers evidently 
   invented entries when the true facts were unknown, without 
   reporting which entries were known and which were invented. 
   These books often contradict each other or give implausible entries, 
   and on the rare occasions when they are checked they are 
   typically found to be incorrect. 
 
 * For the UK the tz database relies on years of first-class work done by 
   Joseph Myers and others; see <http://www.polyomino.org.uk/british-time/>. 
   Other countries are not done nearly as well. 
 
 * Sometimes, different people in the same city would maintain clocks 
   that differed significantly.  Railway time was used by railroad 
   companies (which did not always agree with each other), 
   church-clock time was used for birth certificates, etc. 
   Often this was merely common practice, but sometimes it was set by law. 
   For example, from 1891 to 1911 the UT offset in France was legally 
   0:09:21 outside train stations and 0:04:21 inside. 
 
 * Although a named location in the tz database stands for the 
   containing region, its pre-1970 data entries are often accurate for 
   only a small subset of that region.  For example, Europe/London 
   stands for the United Kingdom, but its pre-1847 times are valid 
   only for locations that have London's exact meridian, and its 1847 
   transition to GMT is known to be valid only for the L&NW and the 
   Caledonian railways. 
 
 * The tz database does not record the earliest time for which a zone's 
   data entries are thereafter valid for every location in the region. 
   For example, Europe/London is valid for all locations in its 
   region after GMT was made the standard time, but the date of 
   standardization (1880-08-02) is not in the tz database, other than 
   in commentary.  For many zones the earliest time of validity is 
   unknown. 
 
 * The tz database does not record a region's boundaries, and in many 
   cases the boundaries are not known.  For example, the zone 
   America/Kentucky/Louisville represents a region around the city of 
   Louisville, the boundaries of which are unclear. 
 
 * Changes that are modeled as instantaneous transitions in the tz 
   database were often spread out over hours, days, or even decades. 
 
 * Even if the time is specified by law, locations sometimes 
   deliberately flout the law. 
 
 * Early timekeeping practices, even assuming perfect clocks, were 
   often not specified to the accuracy that the tz database requires. 
 
 * Sometimes historical timekeeping was specified more precisely 
   than what the tz database can handle.  For example, from 1909 to 
   1937 Netherlands clocks were legally UT+00:19:32.13, but the tz 
   database cannot represent the fractional second. 
 
 * Even when all the timestamp transitions recorded by the tz database 
   are correct, the tz rules that generate them may not faithfully 
   reflect the historical rules.  For example, from 1922 until World 
   War II the UK moved clocks forward the day following the third 
   Saturday in April unless that was Easter, in which case it moved 
   clocks forward the previous Sunday.  Because the tz database has no 
   way to specify Easter, these exceptional years are entered as 
   separate tz Rule lines, even though the legal rules did not change. 
 
 * The tz database models pre-standard time using the Gregorian 
   calendar and local mean time (LMT), but many people used other 
   calendars and other timescales.  For example, the Roman Empire used 
   the Julian calendar, and had 12 varying-length daytime hours with a 
   non-hour-based system at night. 
 
 * Early clocks were less reliable, and data entries do not represent 
   this unreliability. 
 
 * As for leap seconds, civil time was not based on atomic time before 
   1972, and we don't know the history of earth's rotation accurately 
   enough to map SI seconds to historical solar time to more than 
   about one-hour accuracy.  See: Morrison LV, Stephenson FR. 
   Historical values of the Earth's clock error Delta T and the 
   calculation of eclipses. J Hist Astron. 2004;35:327-36 
   <http://adsabs.harvard.edu/full/2004JHA....35..327M>; 
   Historical values of the Earth's clock error. J Hist Astron. 2005;36:339 
   <http://adsabs.harvard.edu/full/2005JHA....36..339M>. 
 
 * The relationship between POSIX time (that is, UTC but ignoring leap 
   seconds) and UTC is not agreed upon after 1972.  Although the POSIX 
   clock officially stops during an inserted leap second, at least one 
   proposed standard has it jumping back a second instead; and in 
   practice POSIX clocks more typically either progress glacially during 
   a leap second, or are slightly slowed while near a leap second. 
 
 * The tz database does not represent how uncertain its information is. 
   Ideally it would contain information about when data entries are 
   incomplete or dicey.  Partial temporal knowledge is a field of 
   active research, though, and it's not clear how to apply it here. 
 
In short, many, perhaps most, of the tz database's pre-1970 and future 
time stamps are either wrong or misleading.  Any attempt to pass the 
tz database off as the definition of time should be unacceptable to 
anybody who cares about the facts.  In particular, the tz database's 
LMT offsets should not be considered meaningful, and should not prompt 
creation of zones merely because two locations differ in LMT or 
transitioned to standard time at different dates. 
 
 
----- Names of time zone rule files ----- 
 
The time zone rule file naming conventions attempt to strike a balance 
among the following goals: 
 
 * Uniquely identify every national region where clocks have all 
   agreed since 1970.  This is essential for the intended use: static 
   clocks keeping local civil time. 
 
 * Indicate to humans as to where that region is.  This simplifies use. 
 
 * Be robust in the presence of political changes.  This reduces the 
   number of updates and backward-compatibility hacks.  For example, 
   names of countries are ordinarily not used, to avoid 
   incompatibilities when countries change their name 
   (e.g. Zaire->Congo) or when locations change countries 
   (e.g. Hong Kong from UK colony to China). 
 
 * Be portable to a wide variety of implementations. 
   This promotes use of the technology. 
 
 * Use a consistent naming convention over the entire world. 
   This simplifies both use and maintenance. 
 
This naming convention is not intended for use by inexperienced users 
to select TZ values by themselves (though they can of course examine 
and reuse existing settings).  Distributors should provide 
documentation and/or a simple selection interface that explains the 
names; see the 'tzselect' program supplied with this distribution for 
one example. 
 
Names normally have the form AREA/LOCATION, where AREA is the name 
of a continent or ocean, and LOCATION is the name of a specific 
location within that region.  North and South America share the same 
area, 'America'.  Typical names are 'Africa/Cairo', 'America/New_York', 
and 'Pacific/Honolulu'. 
 
Here are the general rules used for choosing location names, 
in decreasing order of importance: 
 
        Use only valid POSIX file name components (i.e., the parts of 
                names other than '/').  Do not use the file name 
                components '.' and '..'.  Within a file name component, 
                use only ASCII letters, '.', '-' and '_'.  Do not use 
                digits, as that might create an ambiguity with POSIX 
                TZ strings.  A file name component must not exceed 14 
                characters or start with '-'.  E.g., prefer 'Brunei' 
                to 'Bandar_Seri_Begawan'.  Exceptions: see the discussion 
                of legacy names below. 
        A name must not be empty, or contain '//', or start or end with '/'. 
        Do not use names that differ only in case.  Although the reference 
                implementation is case-sensitive, some other implementations 
                are not, and they would mishandle names differing only in case. 
        If one name A is an initial prefix of another name AB (ignoring case), 
                then B must not start with '/', as a regular file cannot have 
                the same name as a directory in POSIX.  For example, 
                'America/New_York' precludes 'America/New_York/Bronx'. 
        Uninhabited regions like the North Pole and Bouvet Island 
                do not need locations, since local time is not defined there. 
        There should typically be at least one name for each ISO 3166-1 
                officially assigned two-letter code for an inhabited country 
                or territory. 
        If all the clocks in a region have agreed since 1970, 
                don't bother to include more than one location 
                even if subregions' clocks disagreed before 1970. 
                Otherwise these tables would become annoyingly large. 
        If a name is ambiguous, use a less ambiguous alternative; 
                e.g. many cities are named San José and Georgetown, so 
                prefer 'Costa_Rica' to 'San_Jose' and 'Guyana' to 'Georgetown'. 
        Keep locations compact.  Use cities or small islands, not countries 
                or regions, so that any future time zone changes do not split 
                locations into different time zones.  E.g. prefer 'Paris' 
                to 'France', since France has had multiple time zones. 
        Use mainstream English spelling, e.g. prefer 'Rome' to 'Roma', and 
                prefer 'Athens' to the Greek 'Αθήνα' or the Romanized 'Athína'. 
                The POSIX file name restrictions encourage this rule. 
        Use the most populous among locations in a zone, 
                e.g. prefer 'Shanghai' to 'Beijing'.  Among locations with 
                similar populations, pick the best-known location, 
                e.g. prefer 'Rome' to 'Milan'. 
        Use the singular form, e.g. prefer 'Canary' to 'Canaries'. 
        Omit common suffixes like '_Islands' and '_City', unless that 
                would lead to ambiguity.  E.g. prefer 'Cayman' to 
                'Cayman_Islands' and 'Guatemala' to 'Guatemala_City', 
                but prefer 'Mexico_City' to 'Mexico' because the country 
                of Mexico has several time zones. 
        Use '_' to represent a space. 
        Omit '.' from abbreviations in names, e.g. prefer 'St_Helena' 
                to 'St._Helena'. 
        Do not change established names if they only marginally 
                violate the above rules.  For example, don't change 
                the existing name 'Rome' to 'Milan' merely because 
                Milan's population has grown to be somewhat greater 
                than Rome's. 
        If a name is changed, put its old spelling in the 'backward' file. 
                This means old spellings will continue to work. 
 
The file 'zone1970.tab' lists geographical locations used to name time 
zone rule files.  It is intended to be an exhaustive list of names 
for geographic regions as described above; this is a subset of the 
names in the data.  Although a 'zone1970.tab' location's longitude 
corresponds to its LMT offset with one hour for every 15 degrees east 
longitude, this relationship is not exact. 
 
Older versions of this package used a different naming scheme, 
and these older names are still supported. 
See the file 'backward' for most of these older names 
(e.g., 'US/Eastern' instead of 'America/New_York'). 
The other old-fashioned names still supported are 
'WET', 'CET', 'MET', and 'EET' (see the file 'europe'). 
 
Older versions of this package defined legacy names that are 
incompatible with the first rule of location names, but which are 
still supported.  These legacy names are mostly defined in the file 
'etcetera'.  Also, the file 'backward' defines the legacy names 
'GMT0', 'GMT-0', 'GMT+0' and 'Canada/East-Saskatchewan', and the file 
'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT', 
'MST7MDT', and 'PST8PDT'. 
 
Excluding 'backward' should not affect the other data.  If 
'backward' is excluded, excluding 'etcetera' should not affect the 
remaining data. 
 
 
----- Time zone abbreviations ----- 
 
When this package is installed, it generates time zone abbreviations 
like 'EST' to be compatible with human tradition and POSIX. 
Here are the general rules used for choosing time zone abbreviations, 
in decreasing order of importance: 
 
        Use abbreviations that consist of three or more ASCII letters. 
                Previous editions of this database also used characters like 
                ' ' and '?', but these characters have a special meaning to 
                the shell and cause commands like 
                        set `date` 
                to have unexpected effects. 
                Previous editions of this rule required upper-case letters, 
                but the Congressman who introduced Chamorro Standard Time 
                preferred "ChST", so the rule has been relaxed. 
 
                This rule guarantees that all abbreviations could have 
                been specified by a POSIX TZ string.  POSIX 
                requires at least three characters for an 
                abbreviation.  POSIX through 2000 says that an abbreviation 
                cannot start with ':', and cannot contain ',', '-', 
                '+', NUL, or a digit.  POSIX from 2001 on changes this 
                rule to say that an abbreviation can contain only '-', '+', 
                and alphanumeric characters from the portable character set 
                in the current locale.  To be portable to both sets of 
                rules, an abbreviation must therefore use only ASCII 
                letters. 
 
        Use abbreviations that are in common use among English-speakers, 
                e.g. 'EST' for Eastern Standard Time in North America. 
                We assume that applications translate them to other languages 
                as part of the normal localization process; for example, 
                a French application might translate 'EST' to 'HNE'. 
 
        For zones whose times are taken from a city's longitude, use the 
                traditional xMT notation, e.g. 'PMT' for Paris Mean Time. 
                The only name like this in current use is 'GMT'. 
 
        If there is no common English abbreviation, abbreviate the English 
                translation of the usual phrase used by native speakers. 
                If this is not available or is a phrase mentioning the country 
                (e.g. "Cape Verde Time"), then: 
 
                When a country is identified with a single or principal zone, 
                        append 'T' to the country's ISO code, e.g. 'CVT' for 
                        Cape Verde Time.  For summer time append 'ST'; 
                        for double summer time append 'DST'; etc. 
                Otherwise, take the first three letters of an English place 
                        name identifying each zone and append 'T', 'ST', etc. 
                        as before; e.g. 'VLAST' for VLAdivostok Summer Time. 
 
        Use 'LMT' for local mean time of locations before the introduction 
                of standard time; see "Scope of the tz database". 
 
        Use UT (with time zone abbreviation 'zzz') for locations while 
                uninhabited.  The 'zzz' mnemonic is that these locations are, 
                in some sense, asleep. 
 
Application writers should note that these abbreviations are ambiguous 
in practice: e.g. 'CST' has a different meaning in China than 
it does in the United States.  In new applications, it's often better 
to use numeric UT offsets like '-0600' instead of time zone 
abbreviations like 'CST'; this avoids the ambiguity. 
 
 
----- Calendrical issues ----- 
 
Calendrical issues are a bit out of scope for a time zone database, 
but they indicate the sort of problems that we would run into if we 
extended the time zone database further into the past.  An excellent 
resource in this area is Nachum Dershowitz and Edward M. Reingold, 
Calendrical Calculations: Third Edition, Cambridge University Press (2008) 
<http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/>. 
Other information and sources are given below.  They sometimes disagree. 
 
 
France 
 
Gregorian calendar adopted 1582-12-20. 
French Revolutionary calendar used 1793-11-24 through 1805-12-31, 
and (in Paris only) 1871-05-06 through 1871-05-23. 
 
 
Russia 
 
From Chris Carrier (1996-12-02): 
On 1929-10-01 the Soviet Union instituted an "Eternal Calendar" 
with 30-day months plus 5 holidays, with a 5-day week. 
On 1931-12-01 it changed to a 6-day week; in 1934 it reverted to the 
Gregorian calendar while retaining the 6-day week; on 1940-06-27 it 
reverted to the 7-day week.  With the 6-day week the usual days 
off were the 6th, 12th, 18th, 24th and 30th of the month. 
(Source: Evitiar Zerubavel, _The Seven Day Circle_) 
 
 
Mark Brader reported a similar story in "The Book of Calendars", edited 
by Frank Parise (1982, Facts on File, ISBN 0-8719-6467-8), page 377.  But: 
 
From: Petteri Sulonen (via Usenet) 
Date: 14 Jan 1999 00:00:00 GMT 
... 
 
If your source is correct, how come documents between 1929 and 1940 were 
still dated using the conventional, Gregorian calendar? 
 
I can post a scan of a document dated December 1, 1934, signed by 
Yenukidze, the secretary, on behalf of Kalinin, the President of the 
Executive Committee of the Supreme Soviet, if you like. 
 
 
 
Sweden (and Finland) 
 
From: Mark Brader 
Subject: Re: Gregorian reform - a part of locale? 
<news:1996Jul6.012937.29190@sq.com> 
Date: 1996-07-06 
 
In 1700, Denmark made the transition from Julian to Gregorian.  Sweden 
decided to *start* a transition in 1700 as well, but rather than have one of 
those unsightly calendar gaps :-), they simply decreed that the next leap 
year after 1696 would be in 1744 - putting the whole country on a calendar 
different from both Julian and Gregorian for a period of 40 years. 
 
However, in 1704 something went wrong and the plan was not carried through; 
they did, after all, have a leap year that year.  And one in 1708.  In 1712 
they gave it up and went back to Julian, putting 30 days in February that 
year!... 
 
Then in 1753, Sweden made the transition to Gregorian in the usual manner, 
getting there only 13 years behind the original schedule. 
 
(A previous posting of this story was challenged, and Swedish readers 
produced the following references to support it: "Tideräkning och historia" 
by Natanael Beckman (1924) and "Tid, en bok om tideräkning och 
kalenderväsen" by Lars-Olof Lodén (1968). 
 
 
Grotefend's data 
 
From: "Michael Palmer" [with one obvious typo fixed] 
Subject: Re: Gregorian Calendar (was Re: Another FHC related question 
Newsgroups: soc.genealogy.german 
Date: Tue, 9 Feb 1999 02:32:48 -800 
... 
 
The following is a(n incomplete) listing, arranged chronologically, of 
European states, with the date they converted from the Julian to the 
Gregorian calendar: 
 
04/15 Oct 1582 - Italy (with exceptions), Spain, Portugal, Poland (Roman 
                 Catholics and Danzig only) 
09/20 Dec 1582 - France, Lorraine 
 
21 Dec 1582/ 
   01 Jan 1583 - Holland, Brabant, Flanders, Hennegau 
10/21 Feb 1583 - bishopric of Liege (Lüttich) 
13/24 Feb 1583 - bishopric of Augsburg 
04/15 Oct 1583 - electorate of Trier 
05/16 Oct 1583 - Bavaria, bishoprics of Freising, Eichstedt, Regensburg, 
                 Salzburg, Brixen 
13/24 Oct 1583 - Austrian Oberelsaß and Breisgau 
20/31 Oct 1583 - bishopric of Basel 
02/13 Nov 1583 - duchy of Jülich-Berg 
02/13 Nov 1583 - electorate and city of Köln 
04/15 Nov 1583 - bishopric of Würzburg 
11/22 Nov 1583 - electorate of Mainz 
16/27 Nov 1583 - bishopric of Strassburg and the margraviate of Baden 
17/28 Nov 1583 - bishopric of Münster and duchy of Cleve 
14/25 Dec 1583 - Steiermark 
 
06/17 Jan 1584 - Austria and Bohemia 
11/22 Jan 1584 - Lucerne, Uri, Schwyz, Zug, Freiburg, Solothurn 
12/23 Jan 1584 - Silesia and the Lausitz 
22 Jan/ 
   02 Feb 1584 - Hungary (legally on 21 Oct 1587) 
      Jun 1584 - Unterwalden 
01/12 Jul 1584 - duchy of Westfalen 
 
16/27 Jun 1585 - bishopric of Paderborn 
 
14/25 Dec 1590 - Transylvania 
 
22 Aug/ 
   02 Sep 1612 - duchy of Prussia 
 
13/24 Dec 1614 - Pfalz-Neuburg 
 
          1617 - duchy of Kurland (reverted to the Julian calendar in 
                 1796) 
 
          1624 - bishopric of Osnabrück 
 
          1630 - bishopric of Minden 
 
15/26 Mar 1631 - bishopric of Hildesheim 
 
          1655 - Kanton Wallis 
 
05/16 Feb 1682 - city of Strassburg 
 
18 Feb/ 
   01 Mar 1700 - Protestant Germany (including Swedish possessions in 
                 Germany), Denmark, Norway 
30 Jun/ 
   12 Jul 1700 - Gelderland, Zutphen 
10 Nov/ 
   12 Dec 1700 - Utrecht, Overijssel 
 
31 Dec 1700/ 
   12 Jan 1701 - Friesland, Groningen, Zürich, Bern, Basel, Geneva, 
                 Turgau, and Schaffhausen 
 
          1724 - Glarus, Appenzell, and the city of St. Gallen 
 
01 Jan 1750    - Pisa and Florence 
 
02/14 Sep 1752 - Great Britain 
 
17 Feb/ 
   01 Mar 1753 - Sweden 
 
1760-1812      - Graubünden 
 
The Russian empire (including Finland and the Baltic states) did not 
convert to the Gregorian calendar until the Soviet revolution of 1917. 
 
Source: H. Grotefend, _Taschenbuch der Zeitrechnung des deutschen 
Mittelalters und der Neuzeit_, herausgegeben von Dr. O. Grotefend 
(Hannover: Hahnsche Buchhandlung, 1941), pp. 26-28. 
 
 
----- 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 
Rovers mission (2004).  These timepieces look like normal Seikos and 
Citizens but use Mars seconds rather than terrestrial seconds. 
 
A Mars solar day is called a "sol" and has a mean period equal to 
about 24 hours 39 minutes 35.244 seconds in terrestrial time.  It is 
divided into a conventional 24-hour clock, so each Mars second equals 
about 1.02749125 terrestrial seconds. 
 
The prime meridian of Mars goes through the center of the crater 
Airy-0, named in honor of the British astronomer who built the 
Greenwich telescope that defines Earth's prime meridian.  Mean solar 
time on the Mars prime meridian is called Mars Coordinated Time (MTC). 
 
Each landed mission on Mars has adopted a different reference for 
solar time keeping, so there is no real standard for Mars time zones. 
For example, the Mars Exploration Rover project (2004) defined two 
time zones "Local Solar Time A" and "Local Solar Time B" for its two 
missions, each zone designed so that its time equals local true solar 
time at approximately the middle of the nominal mission.  Such a "time 
zone" is not particularly suited for any application other than the 
mission itself. 
 
Many calendars have been proposed for Mars, but none have achieved 
wide acceptance.  Astronomers often use Mars Sol Date (MSD) which is a 
sequential count of Mars solar days elapsed since about 1873-12-29 
12:00 GMT. 
 
The tz database does not currently support Mars time, but it is 
documented here in the hopes that support will be added eventually. 
 
Sources: 
 
Michael Allison and Robert Schmunk, 
"Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock" 
<http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2012-08-08). 
 
Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times 
<http://articles.latimes.com/2004/jan/14/science/sci-marstime14> 
(2004-01-14), pp A1, A20-A21. 
 
 
----- 
Local Variables: 
coding: utf-8 
End: