-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-murchison-rfc8536bis.xml
4700 lines (4457 loc) · 171 KB
/
draft-murchison-rfc8536bis.xml
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
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<?xml-stylesheet type="text/xsl" href="../../rfc2629.xslt"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="3"?>
<?rfc strict="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
docName="draft-murchison-rfc8536bis-15" updates=""
ipr="trust200902" obsoletes="8536" consensus="true"
submissionType="IETF" xml:lang="en" tocInclude="true"
symRefs="true" sortRefs="true" tocDepth="3" version="3">
<!-- xml2rfc v2v3 conversion 3.9.0 -->
<front>
<title abbrev="TZif">
The Time Zone Information Format (TZif)
</title>
<seriesInfo name="Internet-Draft" value="draft-murchison-rfc8536bis-15"/>
<author initials="A.D." surname="Olson" fullname="Arthur David Olson">
<organization/>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="P." surname="Eggert" fullname="Paul Eggert">
<organization abbrev="UCLA">
University of California, Los Angeles
</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="K." surname="Murchison" fullname="Kenneth Murchison">
<organization abbrev="Fastmail">Fastmail US LLC</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date/>
<area>General</area>
<workgroup>Internet Engineering Task Force (IETF)</workgroup>
<keyword>time zone</keyword>
<keyword>tzdata</keyword>
<keyword>tzif</keyword>
<abstract>
<t>This document specifies the Time Zone Information Format (TZif)
for representing and exchanging time zone information,
independent of any particular service or protocol.
Two media types for this format are also defined.
</t>
<t>This document replaces and obsoletes RFC 8536.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>Time zone data typically consists of offsets from universal
time (UT), daylight saving transition rules, one or
more local time designations (acronyms or abbreviations), and
optional leap-second adjustments.
One such format for conveying this information is
<xref target="RFC5545" format="default">iCalendar</xref>.
It is a text-based format used by calendaring and scheduling systems.
</t>
<t>This document specifies the widely deployed Time Zone
Information Format (TZif).
It is a binary format used by most UNIX systems to calculate
local time.
This format was introduced in the 1980s and has evolved since
then into multiple upward-compatible versions.
There is a wide variety of interoperable software capable of
generating and reading files in this format
<xref target="tz-link" format="default"/>.
</t>
<t>This specification does not define the source of the data
assembled into a TZif file.
One such source is the IANA-hosted time zone database
<xref target="RFC6557" format="default"/>.</t>
<t>This document obsoletes RFC 8536, providing editorial improvements,
new details, and errata fixes while keeping full compatibility with
the interchange format of RFC 8536.
Additionally, a new version of the format is defined.
The changes from RFC 8536 are summarized in
<xref target="changes" format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default"/>
<xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>The following terms are used in this document
(see <xref target="tz-link" format="default">
"Time zone and daylight saving time data"</xref>
for more detailed information about civil timekeeping data and
practice):
</t>
<dl newline="false" spacing="normal">
<dt>Coordinated Universal Time (UTC):</dt>
<dd>
The basis for civil time since 1960.
It is approximately equal to mean solar time at the prime
meridian (0 degrees longitude).
</dd>
<dt>Daylight Saving Time (DST):</dt>
<dd>
The time according to a location's law or practice,
when adjusted as necessary from standard time. The
adjustment may be positive or negative, and the amount of
adjustment may vary depending on the date and time; the TZif
format even allows the adjustment to be zero, although this
is not common practice.
</dd>
<dt>International Atomic Time (TAI):</dt>
<dd>
The time standard based on atomic clocks since 1972.
It is equal to UTC but without leap-second adjustments.
</dd>
<dt>Leap Second:</dt>
<dd>
A one-second adjustment to keep UTC close to mean solar time
at the prime meridian
(see <xref target="ITU-R-TF.460" format="default"/>).
Each inserted or deleted leap second occurs at the end of a
UTC month, that is, a month using the Gregorian calendar and
the UTC timescale.
</dd>
<dt>Leap-Second Correction (LEAPCORR):</dt>
<dd>
The value of TAI - UTC - 10 for timestamps after the
first leap second, and zero for timestamps before that.
The expression "TAI - UTC - 10" comes from the fact
that TAI - UTC was defined to be 10 just prior to
the first leap second in 1972, so clocks with leap
seconds have a zero LEAPCORR before the first leap
second.
</dd>
<dt>Local Time:</dt>
<dd>
Civil time for a particular location. Its offset
from universal time can depend on the date and time of day.
</dd>
<dt>POSIX Epoch:</dt>
<dd>
1970-01-01 00:00:00 UTC, the basis for absolute timestamps
in this document.
</dd>
<dt>Standard Time:</dt>
<dd>
The time according to a location's law or practice,
unadjusted for Daylight Saving Time.
</dd>
<dt>Time Change:</dt>
<dd>
<t>
A change to civil timekeeping practice. It occurs when one
or more of the following happen simultaneously:
</t>
<ol spacing="normal" type="1"><li>a change in UT offset</li>
<li>a change in whether daylight saving time is in effect</li>
<li>a change in time zone abbreviation</li>
<li>a leap second (i.e., a change in LEAPCORR)</li>
</ol>
</dd>
<dt>Time Zone Data:</dt>
<dd>
The <xref target="RFC7808" format="default">
Time Zone Data Distribution Service (TZDIST)</xref>
defines "Time zone data" as "data
that defines a single time zone, including an identifier,
UTC offset values, DST rules, and other information such as
time zone abbreviations." The interchange format defined in
this document is one such form of time zone data.
</dd>
<dt>Transition Time:</dt>
<dd>
The moment of occurrence of a time change that is not a leap
second. It is identified with a signed integer count of
UNIX leap time seconds since the POSIX epoch.
</dd>
<dt>Universal Time (UT):</dt>
<dd>
The basis of civil time.
This is the principal form of the mean solar time at the
prime meridian (0 degrees longitude) for timestamps before
UTC was introduced in 1960 and is UTC for timestamps
thereafter.
Although UT is sometimes called "UTC" or "GMT" in other
sources, this specification uses the term "UT" to avoid
confusion with UTC or with GMT.
</dd>
<dt>UNIX Time:</dt>
<dd>
The time as returned by the time() function provided by the C
programming language
(see Section 3 of the "System Interfaces" volume of
<xref target="POSIX" format="default"/>).
This is an integer number of seconds
since the POSIX epoch, not counting
leap seconds. As an extension to POSIX, negative values
represent times before the POSIX epoch, using UT.
</dd>
<dt>UNIX Leap Time:</dt>
<dd>
UNIX time plus all preceding leap-second corrections.
For example, if the first leap-second record in a TZif file
occurs at 1972-06-30 23:59:60 UTC, the UNIX leap time for
the timestamp 1972-07-01 00:00:00 UTC would be 78796801, one
greater than the UNIX time for the same timestamp.
Similarly, if the second leap-second record occurs at
1972-12-31 23:59:60 UTC, it accounts for the first leap second,
so the UNIX leap time of 1972-12-31 23:59:60 UTC would be 94694401,
and the UNIX leap time of 1973-01-01 00:00:00 UTC would be 94694402.
If a TZif file specifies no leap-second records,
UNIX leap time is equal to UNIX time.
</dd>
<dt>Wall Time:</dt>
<dd>
Another name for local time; short for "wall-clock time".
</dd>
</dl>
</section>
<section anchor="format" numbered="true" toc="default">
<name>The Time Zone Information Format (TZif)</name>
<t>The Time Zone Information Format begins with a fixed 44-octet
<xref target="header" format="default">version 1 header</xref>
containing a field that specifies the version
of the file's format. Readers designed for version N can read
version N+1 files without too much trouble; data specific to
version N+1 either appears after version N data so
that earlier-version readers can easily ignore later-version
data they are not designed for, or it appears as a minor
extension to version N that version N readers are likely to
tolerate well.</t>
<t>The version 1 header is followed by a variable-length
<xref target="data" format="default">version 1 data block</xref>
containing four-octet (32-bit) transition times and leap-second
occurrences. These 32-bit values are limited to representing
time changes from 1901-12-13 20:45:52 through 2038-01-19 03:14:07 UT,
and the version 1 header and data block are present only for backward
compatibility with obsolescent readers, as discussed in
<xref target="issues" format="default">
Common Interoperability Issues</xref>.</t>
<t>Version 1 files terminate after the version 1 data block.
Files from versions 2 and higher extend the format by appending a second
44-octet version 2+ header, a variable-length version 2+ data block
containing eight-octet (64-bit) transition times and leap-second
occurrences, and a variable-length
<xref target="footer" format="default">footer</xref>.
These 64-bit values can represent times approximately 292
billion years into the past or future.</t>
<t>
NOTE: All multi-octet integer values MUST be stored in
network octet order format (high-order octet first, otherwise
known as big-endian), with all bits significant. Signed
integer values MUST be represented using two's complement.
</t>
<t>A TZif file is structured as follows:</t>
<figure>
<name>General Format of TZif Files</name>
<artwork type="ascii-art" align="center" name="" alt=""><![CDATA[
Version 1 Versions 2+
+-------------+ +-------------+
| Version 1 | | Version 1 |
| Header | | Header |
+-------------+ +-------------+
| Version 1 | | Version 1 |
| Data Block | | Data Block |
+-------------+ +-------------+
| Version 2+ |
| Header |
+-------------+
| Version 2+ |
| Data Block |
+-------------+
| Footer |
+-------------+
]]></artwork>
</figure>
<section anchor="header" numbered="true" toc="default">
<name>TZif Header</name>
<t>A TZif header is structured as follows
(the lengths of multi-octet fields are shown in parentheses):</t>
<figure>
<name>TZif Header</name>
<artwork type="ascii-art" align="center" name="" alt=""><![CDATA[
+---------------+---+
| magic (4) |ver|
+---------------+---+---------------------------------------+
| [unused - reserved for future use] (15) |
+---------------+---------------+---------------+-----------+
| isutcnt (4) | isstdcnt (4) | leapcnt (4) |
+---------------+---------------+---------------+
| timecnt (4) | typecnt (4) | charcnt (4) |
+---------------+---------------+---------------+
]]></artwork>
</figure>
<t>The fields of the header are defined as follows:</t>
<dl newline="false" spacing="normal">
<dt>magic:</dt>
<dd>
The four-octet <xref target="RFC20" format="default">ASCII</xref>
sequence "TZif" (0x54 0x5A 0x69 0x66),
which identifies the file as utilizing the Time Zone
Information Format.
</dd>
<dt>ver(sion):</dt>
<dd>
<t>
An octet identifying the version of the
file's format. The value MUST be one of the following:
</t>
<dl newline="false" spacing="normal">
<dt>NUL (0x00)</dt>
<dd>
Version 1 - The file contains only the version 1
header and data block.
Version 1 files MUST NOT contain a version 2+ header,
data block, or footer.
</dd>
<dt>'2' (0x32)</dt>
<dd>
Version 2 - The file MUST contain the version 1
header and data block, a version 2+ header and data
block, and a footer.
The TZ string in the
<xref target="footer" format="default">footer</xref>, if
nonempty, MUST strictly adhere to the
requirements for the TZ environment variable
as defined in
Section 8.3 of the "Base Definitions" volume of
<xref target="POSIX" format="default"/>
and MUST encode the POSIX portable character set as
ASCII.
The leap-second records MUST NOT be
<xref target="truncation" format="default">
truncated at the start</xref>,
and MUST NOT contain an expiration time.
</dd>
<dt>'3' (0x33)</dt>
<dd>
Version 3 - The file MUST conform to all version 2
requirements, except that any TZ string in the
<xref target="footer" format="default">footer</xref>
MAY use the TZ string extension
<xref target="tzstrext" format="default">
described below</xref>.
</dd>
<dt>'4' (0x34)</dt>
<dd>
Version 4 - The file MUST conform to all version 3
requirements, except that the leap-second records
MAY be truncated at the start, and
MAY contain an expiration time.
</dd>
</dl>
</dd>
<dt>isutcnt:</dt>
<dd>
A four-octet unsigned integer specifying the number of
UT/local indicators contained in the data block --
MUST either be zero or equal to "typecnt".
</dd>
<dt>isstdcnt:</dt>
<dd>
A four-octet unsigned integer specifying the number of
standard/wall indicators contained in the data block --
MUST either be zero or equal to "typecnt".
</dd>
<dt>leapcnt:</dt>
<dd>
A four-octet unsigned integer specifying the number of
leap-second records contained in the data block.
</dd>
<dt>timecnt:</dt>
<dd>
A four-octet unsigned integer specifying the number of
transition times contained in the data block.
</dd>
<dt>typecnt:</dt>
<dd>
A four-octet unsigned integer specifying the number of
local time type records contained in the data block --
MUST NOT be zero.
(Although local time type records convey no useful
information in files that have nonempty TZ strings but
no transitions, at least one such record is nevertheless
required because many TZif readers reject files that
have zero time types.)
</dd>
<dt>charcnt:</dt>
<dd>
A four-octet unsigned integer specifying the total number
of octets used by the set of time zone designations
contained in the data block - MUST NOT be zero.
The count includes the trailing NUL (0x00) octet at the
end of the last time zone designation.
</dd>
</dl>
<t>Although the version 1 and 2+ headers have the same format,
magic number, and version fields, their count
fields may differ, because the version 1 data can be a subset of
the version 2+ data.</t>
</section>
<section anchor="data" numbered="true" toc="default">
<name>TZif Data Block</name>
<t>A TZif data block consists of seven variable-length
elements, each of which is a series of items. The
number of items in each series is determined by the
corresponding count field in the header. The total length of
each element is calculated by multiplying the number of items
by the size of each item. Therefore, implementations that
do not wish to parse or use the version 1 data block can
calculate its total length and skip directly to the header of
the version 2+ data block.</t>
<t>In the version 1 data block, time values are 32 bits
(TIME_SIZE = 4 octets). In the version 2+ data block, present
only in version 2 and higher files, time values are 64 bits
(TIME_SIZE = 8 octets).</t>
<t>The data block is structured as follows
(the lengths of multi-octet fields are shown in parentheses):</t>
<figure>
<name>TZif Data Block</name>
<artwork type="ascii-art" align="center" name="" alt=""><![CDATA[
+---------------------------------------------------------+
| transition times (timecnt x TIME_SIZE) |
+---------------------------------------------------------+
| transition types (timecnt) |
+---------------------------------------------------------+
| local time type records (typecnt x 6) |
+---------------------------------------------------------+
| time zone designations (charcnt) |
+---------------------------------------------------------+
| leap-second records (leapcnt x (TIME_SIZE + 4)) |
+---------------------------------------------------------+
| standard/wall indicators (isstdcnt) |
+---------------------------------------------------------+
| UT/local indicators (isutcnt) |
+---------------------------------------------------------+
]]></artwork>
</figure>
<t>The elements of the data block are defined as follows:</t>
<dl newline="false" spacing="normal">
<dt>transition times:</dt>
<dd>
A series of four- or eight-octet UNIX leap time values sorted
in strictly ascending order.
Each value is used as a transition time at which the rules
for computing local time may change.
The number of time values is specified by the "timecnt"
field in the header.
Each time value SHOULD be at least -2**59.
(-2**59 is the greatest negated power of 2 that predates
the Big Bang, and avoiding earlier timestamps works
around known TZif reader bugs relating to outlandishly
negative timestamps.)
</dd>
<dt>transition types:</dt>
<dd>
A series of one-octet unsigned integers specifying the
type of local time of the corresponding transition time.
These values serve as zero-based indices into the array
of local time type records.
The number of type indices is specified by the "timecnt"
field in the header.
Each type index MUST be in the range [0, "typecnt" - 1].
</dd>
<dt>local time type records:</dt>
<dd>
<t>
A series of six-octet records specifying a local time
type.
The number of records is specified by the "typecnt"
field in the header.
Each record has the following format
(the lengths of multi-octet fields are shown in parentheses):
</t>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
+---------------+---+---+
| utoff (4) |dst|idx|
+---------------+---+---+
]]></artwork>
<dl newline="false" spacing="normal">
<dt>utoff:</dt>
<dd>
A four-octet signed integer specifying the number of
seconds to be added to UT in order to determine local
time. The value MUST NOT be -2**31 and SHOULD be in
the range [-89999, 93599] (i.e., its value SHOULD be
more than -25 hours and less than 26 hours).
Avoiding -2**31 allows 32-bit clients to negate
the value without overflow.
Restricting it to [-89999, 93599] allows easy support by
implementations that already support the
POSIX-required range [-24:59:59, 25:59:59].
</dd>
<dt>(is)dst:</dt>
<dd>
A one-octet value indicating whether local
time should be considered Daylight Saving Time (DST).
The value MUST be 0 or 1.
A value of one (1) indicates that this type of time is DST.
A value of zero (0) indicates that this time type
is standard time.
</dd>
<dt>(desig)idx:</dt>
<dd>
A one-octet unsigned integer specifying a zero-based
index into the series of time zone designation octets,
thereby selecting a particular designation string.
Each index MUST be in the range [0, "charcnt" - 1]; it
designates the NUL&nbhy;terminated string of octets
starting at position "idx" in the time zone
designations. (This string MAY be empty.) A NUL
octet MUST exist in the time zone designations at or
after position "idx".
If the designation string is "-00", the time type is a
placeholder indicating that local time is unspecified.
</dd>
</dl>
</dd>
<dt>time zone designations:</dt>
<dd>
A series of octets constituting an array of
NUL&nbhy;terminated (0x00) time zone designation strings.
The total number of octets is specified by the
"charcnt" field in the header.
Two designations MAY overlap if one is a
suffix of the other.
The character encoding of time zone designation strings
is not specified; however,
see <xref target="interop" format="default"/>
of this document.
</dd>
<dt>leap-second records:</dt>
<dd>
<t>
A series of eight- or twelve-octet records specifying
the corrections that need to be applied to UTC in order to
determine TAI, also known as the leap-second table.
The records are sorted by the occurrence time in
strictly ascending order.
The number of records is specified by the
"leapcnt" field in the header.
Each record has one of the following structures
(the lengths of multi-octet fields are shown in parentheses):
</t>
<dl newline="false" spacing="normal">
<dt>Version 1 Data Block:</dt>
<dd>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
+---------------+---------------+
| occur (4) | corr (4) |
+---------------+---------------+
]]></artwork>
</dd>
<dt>version 2+ Data Block:</dt>
<dd>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
+---------------+---------------+---------------+
| occur (8) | corr (4) |
+---------------+---------------+---------------+
]]></artwork>
</dd>
</dl>
<dl newline="false" spacing="normal">
<dt>occur(rence):</dt>
<dd>
A four- or eight-octet UNIX leap time value specifying the
time at which a leap-second correction occurs
or at which the leap-second table expires.
The first value, if present, MUST be nonnegative,
and each leap second MUST occur at the end of a UTC
month.
</dd>
<dt>corr(ection):</dt>
<dd>
<t>
A four-octet signed integer specifying the value
of LEAPCORR on or after the occurrence.
If "leapcnt" is zero, LEAPCORR is zero for all timestamps;
otherwise, for timestamps before the first occurrence time,
LEAPCORR is zero if the first correction is one (1)
or minus one (-1),
and is unspecified otherwise (which can happen only in files
<xref target="truncation" format="default">
truncated at the start</xref>).
</t>
<t>
The first leap second is a positive leap second if and
only if its correction is positive.
Each correction after the first MUST differ from the
previous correction by either
one (1) for a positive leap second or
minus one (-1) for a negative leap second,
except that in version 4 files with two or more leap-second
records, the correction value of the last two records
MAY be the same, with the occurrence of last record
indicating the expiration time of the leap-second table.
</t>
<t>
The leap-second table expiration time is the time at
which the table no longer records the presence or
absence of future leap-second corrections, and
post-expiration timestamps can not be accurately calculated.
For example, a leap-second table published in
January, which predicts the presence or absence of a
leap second at June's end, might expire in
mid-December because it is not known when the next leap
second will occur.
</t>
<t>
If leap seconds become permanently
discontinued, as requested by the
<xref target="CGPM-2022-R4">General Conference
on Weights and Measures</xref>, leap-second tables
published after the discontinuation time
SHOULD NOT expire, since they will not be updated in
the foreseeable future.
</t>
</dd>
</dl>
</dd>
<dt>standard/wall indicators:</dt>
<dd anchor="stdwall">
A series of one-octet values indicating whether
the transition times associated with local time types were
specified as standard time or wall-clock time.
Each value MUST be 0 or 1.
A value of one (1) indicates standard time. The value
MUST be set to one (1) if the corresponding
UT/local indicator is set to one (1).
A value of zero (0) indicates wall time.
The number of values is specified by the "isstdcnt"
field in the header.
If "isstdcnt" is zero (0), all transition times
associated with local time types are assumed to be
specified as wall time.
</dd>
<dt>UT/local indicators:</dt>
<dd anchor="utlocal">
A series of one-octet values indicating whether
the transition times associated with local time types were
specified as UT or local time.
Each value MUST be 0 or 1.
A value of one (1) indicates UT,
and the corresponding standard/wall indicator MUST also
be set to one (1).
A value of zero (0) indicates local time.
The number of values is specified by the "isutcnt"
field in the header.
If "isutcnt" is zero (0), all transition times
associated with local time types are assumed to be
specified as local time.
</dd>
</dl>
<t>The type corresponding to a transition time specifies local
time for timestamps starting at the given transition time and
continuing up to, but not including, the next transition time.
Local time for timestamps before the first transition is
specified by the first time type (time type 0).
Local time for timestamps on or after the last transition is
specified by the TZ string in the
<xref target="footer" format="default">footer</xref>
if present and nonempty; otherwise, it is unspecified.
If there are no transitions, local time for all timestamps is
specified by the TZ string in the footer if present and
nonempty; otherwise, it is specified by time type 0.
A time type with a designation string of "-00" represents an
unspecified local time.
</t>
<t>A given pair of standard/wall and UT/local indicators is
used to designate whether the corresponding transition time
was specified as UT, standard time, or wall-clock time.
There are only three combinations of the two
indicators, given that the standard/wall value MUST be one
(1) if the UT/local value is one (1).
This information can be useful if the transition times in a
TZif file need to be transformed into transitions
appropriate for another time zone (e.g. when calculating
transition times for a simple POSIX-like TZ string such as
"AKST9AKDT").</t>
<t>In order to eliminate unused space in a TZif file, every
nonzero local time type index SHOULD appear at least once in the
transition type array.
Likewise, every octet in the time zone designations array
SHOULD be used by at least one time type record.</t>
</section>
<section anchor="footer" numbered="true" toc="default">
<name>TZif Footer</name>
<t>The TZif footer is structured as follows
(the lengths of multi-octet fields are shown in parentheses):</t>
<figure>
<name>TZif Footer</name>
<artwork type="ascii-art" align="center" name="" alt=""><![CDATA[
+---+--------------------+---+
| NL| TZ string (0...) |NL |
+---+--------------------+---+
]]></artwork>
</figure>
<t>The elements of the footer are defined as follows:</t>
<dl newline="false" spacing="normal">
<dt>NL:</dt>
<dd>
An ASCII new line character (0x0A).
</dd>
<dt>TZ string:</dt>
<dd>
A rule for computing local time changes after the last
transition time stored in the version 2+ data block.
The string is either empty or uses the expanded format
of the "TZ" environment variable as defined in
Section 8.3 of the "Base Definitions" volume of
<xref target="POSIX" format="default"/> with ASCII
encoding, possibly utilizing the
<xref target="tzstrext" format="default">
extension described below</xref>
in version 3 and higher files.
If the string is empty, the corresponding information is
not available.
If the string is nonempty and one or more transitions
appear in the version 2+ data, the string MUST be
consistent with the last version 2+ transition. In other words,
evaluating the TZ string at the time of the last
transition should yield the same time type as was specified in
the last transition.
The string MUST NOT contain NUL octets or be
NUL&nbhy;terminated, and it
SHOULD NOT begin with the ':' (colon) character.
</dd>
</dl>
<t>The TZif footer is present only in version 2 and higher files,
as the obsolescent version 1 format was designed before the
need for a footer was apparent.</t>
<section anchor="permdst" numbered="true" toc="default">
<name>All-Year Daylight Saving Time</name>
<t>DST is considered to be in effect all year if its UT
offset is less than (i.e., west of) that of standard time,
and it starts January 1 at 00:00 and ends December 31 at
24:00 minus the difference between standard and daylight
saving time, leaving no room for standard time
in the calendar.
<xref target="POSIX" format="default"/> implies, but does not
explicitly state this, so it is spelled out here for clarity.
</t>
<dl newline="true" spacing="normal">
<dt>Example: XXX3EDT4,0/0,J365/23</dt>
<dd>
This represents a time zone that is perpetually 4 hours
west of UT and is abbreviated "EDT".
The "XXX" is ignored.
</dd>
</dl>
</section>
<section anchor="tzstrext" numbered="true" toc="default">
<name>TZ String Extension</name>
<t>The TZ string in a version 3 or higher TZif file MAY use the
following extension to POSIX TZ strings.
This extension is described using the terminology of
Section 8.3 of the "Base Definitions" volume of
<xref target="POSIX" format="default"/>.
</t>
<ul spacing="normal">
<li>
<t>The hours part of the transition times may be
signed and range from -167 through 167
(-167 <= hh <= 167) instead of
the POSIX-required unsigned values from 0 through 24.
</t>
<dl newline="true" spacing="normal">
<dt>Example: <-03>3<-02>,M3.5.0/-2,M10.5.0/-1</dt>
<dd>
This represents a time zone that observes daylight
saving time from 22:00 on the day before March's last
Sunday until 23:00 on the day before October's last
Sunday. Standard time is 3 hours west of UT and is
abbreviated "-03"; daylight saving time is 2 hours
west of UT and is abbreviated "-02".
</dd>
</dl>
</li>
</ul>
<t>A TZif file that uses the above extension
MUST be designated as version 3 (or higher),
even if a future version of POSIX adopts this extension.</t>
</section>
</section>
</section>
<section anchor="interop" numbered="true" toc="default">
<name>Interoperability Considerations</name>
<t>The following practices help ensure the interoperability of TZif
applications.</t>
<ul spacing="normal">
<li>Version 1 files are considered a legacy format and
SHOULD NOT be generated, as they do not support transition
times after the year 2038.</li>
<li>Readers that understand only version 1 MUST ignore
any data that extends beyond the calculated end of the version
1 data block.</li>
<li>Other than version 1, writers SHOULD generate the lowest
version number needed by a file's data.
This helps interoperability with older readers.
For example, a writer
SHOULD generate a version 4 file only if its leap-second table
either expires or is truncated at the start. Likewise, a
writer not generating a version 4 file SHOULD generate a
version 3 file only if the TZ string extension is necessary to
accurately model transition times.</li>
<li>To save space, writers of version 2+ files MAY output a
placeholder version 1 data block with all counts zero except
that "typecnt" and "charcnt" are both one (1).
If this is done, obsolescent version-1-only readers MUST
interpret these files as lacking time changes and time zone
abbreviations.</li>
<li>Unless the version 1 data block is a placeholder,
the sequence of timestamps defined by the version 1
header and data block SHOULD be a contiguous sub-sequence
of the timestamps defined by the version 2+ header and data
block, and by the footer.
This guideline helps obsolescent version 1 readers
agree with current readers about timestamps within the
contiguous sub-sequence.</li>
<li>When a TZif file contains a leap-second table expiration
time, TZif readers SHOULD either refuse to process
post-expiration timestamps, or process them as if the expiration
time did not exist (possibly with an error indication).
This lessens disagreement among implementations when
processing far-future timestamps that cannot yet be handled
exactly.</li>
<li>Time zone designations MUST consist of at least three (3)
and no more than six (6) ASCII characters from the set of
alphanumerics, '-', and '+'.
This is compatible with POSIX requirements for
time zone abbreviations.</li>
<li>A reader that encounters a time zone designation containing
bytes other than ASCII alphanumerics, '-', and '+' SHOULD
act if the designation instead contained a signed numeric string
derived from the UT offset, for example, "-10" and "+0530" to
indicate 10 hours west and 5.5 hours east of Greenwich,
respectively.</li>
<li>When reading a version 2 or higher file, readers
SHOULD ignore the version 1 header and data block except for
the purpose of skipping over them.
This improves compatibility among readers of nonconforming
files where version 2+ data is not upward compatible with
version 1.</li>
<li>Readers SHOULD calculate the total lengths of the
headers and data blocks and check that they all fit within
the actual file size, as part of a validity check for the file.</li>
<li>
<t>When a TZif file is used in a MIME message entity, it SHOULD
be indicated by one of the following media types:</t>
<ul spacing="normal">
<li>
<xref target="tzif-leap" format="default">
"application/tzif-leap"</xref>
to indicate that leap-second records are included in the
TZif data as necessary (none are necessary if the file
is truncated to a range that precedes the first leap
second).</li>
<li>
<xref target="tzif" format="default">"application/tzif"</xref>
to indicate that leap-second records are not included in the
TZif data; "leapcnt" in the header(s) MUST be zero (0).</li>
</ul>
</li>
<li>Common interoperability issues and possible workarounds
are described in <xref target="issues" format="default"/>.</li>
</ul>
</section> <!-- interop -->
<section anchor="i18n" numbered="true" toc="default">
<name>Internationalization Considerations</name>
<t>TZif time zone designations contain only ASCII alphanumerics,
"-", and "+". Commonly used designations include numeric strings
like "-10" and "+0530" for UT offsets, and English-language
abbreviations like "CEST" for Central European Summer Time and
"GMT" for Greenwich Mean Time. It is the TZif reader's
responsibility to substitute different abbreviations when needed
for internationalization, such as substituting "HNC" (l'heure
normale du Centre) for "CST" (Central Standard Time) in
French-speaking regions. This substitution can be problematic,
as abbreviations can be ambiguous: for example, "CST" commonly
stands for China Standard Time and Cuba Standard Time as well as
Central Standard Time. One approach for addressing this issue
can be found in the timezone charts of the
<xref target="CLDR">
Unicode Common Locale Data Repository (CLDR) Project.</xref></t>
<t>Although the original TZif design allowed for any nonzero
octets in time zone designations and it was common practice
until the mid-1990s for designations to contain ASCII spaces,
designations are now limited to ASCII alphanumerics, "-", and
"+" to avoid confusion and to encourage portability to a wide
variety of locales.</t>
</section> <!-- i18n -->
<section anchor="tzdist" numbered="true" toc="default">
<name>Use with the Time Zone Data Distribution Service</name>
<t>The <xref target="RFC7808" format="default">Time Zone Data Distribution
Service (TZDIST)</xref> is a service that allows reliable,
secure, and fast delivery of time zone data and leap-second
rules to client systems such as calendaring and scheduling
applications or operating systems.</t>
<t>A TZDIST service MAY supply time zone data to clients in
the Time Zone Information Format. Such a service MUST indicate
that it supports this format by including the media type
<xref target="tzif" format="default">"application/tzif"</xref> in its
"capabilities" response
(<xref target="RFC7808" section="5.1" format="default"/>).
A TZDIST service MAY also include the media type
<xref target="tzif-leap" format="default">
"application/tzif-leap"</xref> in its
"capabilities" response if it is able to generate TZif files
containing leap-second records.
A TZDIST service MUST NOT advertise the "application/tzif-leap"
media type without also advertising "application/tzif".</t>