comments on DHCP time zone draft (draft-ietf-dhc-timezone-03.txt)
Paul Eggert
eggert at twinsun.com
Fri Aug 1 02:08:03 UTC 1997
Here are some comments on your document:
DHCP Option for IEEE 1003.1 POSIX Timezone Specifications
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-timezone-03.txt
(1997-07-30)
* The draft allows only time zone settings that conform to POSIX.1.
However, in practice, these settings are not enough to satisfy
many real-world applications, for the following reasons:
- Due to politics, time zone rules change with time, and POSIX settings
cannot capture these changes. For example, last year the time
zone in Sri Lanka changed from +0530 to +0630 on May 25, and then
to +0600 on Oct 26. POSIX rules cannot represent the time in Sri
Lanka last year.
- Some countries use periodic rules that cannot be represented by
POSIX rules. Examples include Israel (which uses rules based on
the Jewish calendar) and Iran (the Persian calendar). Again,
POSIX rules cannot represent changes like these, except for one
or two transitions at a time.
- Many hosts use the Olson extension to POSIX.1
<ftp://elsie/nci/nih/gov/pub/tz/>
The draft gives no way to specify time zone rules using the Olson
extension, and so these hosts cannot be configured as desired.
The Olson time zone settings are upward compatible with POSIX.1.
They are widely used in practice: the source code and tables are
public domain, and they are supported by many types of hosts, including
BSD, HPUX, Irix, Linux, Network Appliance, Sun, and Unixware.
Therefore I propose that the draft be changed to also allow time zone
settings that conform to the Olson extension to POSIX.1.
Perhaps the DHCP server could reply with both an Olson setting (for
clients that support the Olson extension) and a POSIX.1 setting (for
clients that don't).
* There are several discrepancies between the latest POSIX.1 spec
for TZ format and the DHCP time zone draft. They should be removed
by copying the latest POSIX.1 spec's wording more carefully.
Here are some example discrepancies.
- The `,' and `[' before `start' should be interchanged. In other words,
`stdoffset[dst[offset],[start[/time],end[/time]]]' should be
`stdoffset[dst[offset][,start[/time],end[/time]]]'.
- The current POSIX spec places an upper bound of {TZNAME_MAX} on
the length of a time zone designation like "EST"; the draft
does not have this limit.
- The current POSIX spec does not allow null characters in
a time zone designation.
- The current POSIX spec allows hour=24.
- The current POSIX spec explicitly says that day 0 is Sunday.
* The example for the Eastern USA time zone, 1986 is unrealistic.
In practice, people want to avoid changing their time zone settings
every year, so they rarely use Julian day rules.
Here is a better set of examples (subject to change at any time
by political events):
Eastern USA from 1987:
EST5EDT,M4.1.0,M10.5.0
EST (-0500) during winter
EDT (-0400) during summer
summer time from the 1st Sunday in April at 02:00
to the last Sunday in October at 02:00
Central European Union from 1996:
CET-1CEST,M3.5.0/1,M10.5.0/2
CET (+0100) during winter
CEST (+0200) during summer
summer time from the last Sunday in March at 01:00
to the last Sunday in October at 02:00
Arizona from 1968:
MST7
MST (-0700) all year
Tasmania from 1991:
EST-10EST,M10.1.0/2,M3.5.0/3
EST (+1000) during winter (``Eastern Standard Time'')
EST (+1100) during summer (``Eastern Summer Time'')
summer time from the the first Sunday in October at 02:00
to the last Sunday in March at 03:00
Cook Islands from 1979:
CKT-10CKST-10:30,M10.5.0/0,M3.1.0/0
CKT (+1000) during winter
CKST (+1030) during summer
summer time from the first Sunday in October at 00:00
to the first Sunday in March at 00:00
Line Islands from 1995:
LINT-14
LINT (+1400) all year
If you accept my suggestion for the Olson extension, here are
some more examples (which should be valid indefinitely):
Eastern USA:
America/New_York
Central European Union:
Europe/Brussels
Arizona:
America/Phoenix
Tasmania:
Australia/Hobart
Cook Islands:
Pacific/Rarotonga
Line Islands, Kiribati:
Pacific/Kiritimati
* Please consider adding the following references:
ftp://ds.internic.net/internet-drafts/draft-newman-datetime-01.txt
contains a proposed procedure for IANA registration of
time zone names, and uses the Olson extension as its basis.
ftp://elsie/nci/nih/gov/pub/tz/
contains public-domain code and data for the Olson extension
to the POSIX time zone strings.
The current version of POSIX.1 is:
ISO/IEC 9945-1: 1996 (ANSI/IEEE Std 1003.1, 1996)
Information technology -- Portable Operating System Interface (POSIX) --
Part 1: System Application Program Interface (API) [C Language]
(1996-07-12), section 8.1.1, Extensions to Time Functions
* Terminology.
The usual terms are `time zone' (not `timezone') and
`daylight-saving time' (not `daylight savings time').
The draft should be reworked to use the usual terms.
POSIX.1 currently uses `summer time' (the British term)
instead of `daylight-saving time' (the American term).
Whichever term is used, the draft should mention its equivalence
to the other term.
More information about the tz
mailing list