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