Subject: RE: [dhcwg] timezone draft

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 11 Mar 2006 22:19:40 -0500

With John's suggested approach, isn't there a nasty issue if at 2:00AM
on the date of time changes all of the clients in the network need to
get new information? That may flood the network and servers.

Also, that approach presumes that none of the clients care to provide
information about time in the future or past (i.e., display an upcoming
event as xDT instead of xST for those of us in the US)?

- Bernie 

> -----Original Message-----
> From: John Schnizlein (jschnizl) 
> Sent: Wednesday, March 08, 2006 8:39 AM
> To: Eliot Lear
> Cc: [email-masked]
> Subject: Re: [dhcwg] timezone draft
> 
> 
> On Mar 7, 2006, at 3:30 AM, Eliot Lear wrote:
> 
> > Draft now available.
> > ...	
> > DHCP defines an option for a server to deliver to a client offset
> > from UTC.  This information in and of itself is not sufficient for
> > devices to portray local time both accurately and 
> consistently.  This
> > memo specifies a new option for both DHCPv4 and DHCPv6 to do so.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-lear-dhc-timezone-option 
> > -02.txt
> 
> The scholarship of documenting various encodings for the Daylight  
> Saving time changes in this draft is impressive.  The 
> argument that the  
> static offset specified in RFC 2132 is inadequate is convincing.  
> Although it might seem that changing the offset in the middle of the  
> night twice a year is rare enough for a static configuration 
> parameter,  
> the synchronization of this event is a problem.
> 
> The TZ database appears to be overkill for solving the 
> problem, and an  
> entry of the form:
> 
> "EST5EDT4,M3.2.0/02:00,M11.1.0/02:00"
> 
> duplicates the function (in the "EST5EDT4" portion) of the existing  
> DHCP option:
> 
> > 3.4. Time Offset
> >
> >    The time offset field specifies the offset of the 
> client's subnet in
> >    seconds from Coordinated Universal Time (UTC).  The offset is
> >    expressed as a two's complement 32-bit integer.  A 
> positive offset
> >    indicates a location east of the zero meridian and a 
> negative offset
> >    indicates a location west of the zero meridian.
> >
> >    The code for the time offset option is 2, and its length is 4  
> > octets.
> >
> >     Code   Len        Time Offset
> >    +-----+-----+-----+-----+-----+-----+
> >    |  2  |  4  |  n1 |  n2 |  n3 |  n4 |
> >    +-----+-----+-----+-----+-----+-----+
> 
> A simpler approach would be an option that indicates at what 
> time the  
> offset should next change and to what value.  This enables a 
> RENEW or  
> INFORM message any time during the next time cycle to get the next  
> change.  It also allows for changes such as the complex set 
> for Indiana  
> this April, and the legal change for the United States in 
> March of next  
> year. [http://en.wikipedia.org/wiki/Daylight_saving] Automatically  
> configuring one change at a time avoids errors from (humans) 
> failing to  
> update the TZ database with new entries.  The 
> time-to-change-offset and  
> new-offset should be 32-bit two's complement integers for 
> compatibility  
> with the existing offset.
> 
> Defining multiple sub-options for different cases should be avoided  
> when possible.  Defining different sub-options for different current  
> operating systems is a bad idea.
> 
> John
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: John Schnizlein <[email-masked]>
Date: Sun, 12 Mar 2006 12:39:39 -0500

Answers embedded:

> get new information? That may flood the network and servers.

No,  that nasty issue is what could occur with no change from the 
current static time-zone offset.

The synchronized need for new information is eliminated by giving 
clients the time of the next change and the offset to which to change.  
Clients then have all the time up until the subsequent time change to 
renew or query (INFORM) to get the current offset, next change time and 
next offset.

> event as xDT instead of xST for those of us in the US)?

No such presumption is included in the approach, although it is 
focussed on the identified problem - eliminating synchronized updates 
to the offset - not a new goal of providing for display features of 
time-zone changes.  My proposal provides for correct local time 
adjusted by the daylight saving (or other arbitrary scheduled change in 
time-zone) offset.

The dates at which time-zone offsets change have not been stable at the 
values in the TZ database; governments of various scope have changed 
the application of daylight saving, and the dates of application, to 
suit political purposes over time.  The alternative proposed in the 
draft does not provide complete history of all of the changes either, 
nor should it.  An application that needs time-zone- and 
daylight-saving-adjusted display of past and future times should employ 
archival tables of the large number of changes.  DHCP is not the 
appropriate protocol to distribute the history and legislated future of 
time adjustments.

John

---

From: Robert Elz <[email-masked]>
Date: Tue, 14 Mar 2006 14:06:00 +0700

Date:        Sun, 12 Mar 2006 12:39:39 -0500
    From:        John Schnizlein <[email-masked]>
    Message-ID:  <[email-masked]>

  | The synchronized need for new information is eliminated by giving 
  | clients the time of the next change and the offset to which to change.  
  | Clients then have all the time up until the subsequent time change to 
  | renew or query (INFORM) to get the current offset, next change time and 
  | next offset.

That's almost unworkable - it requires clients to remember what it is
they need to ask sometime in the future, and make sure that they
remember to do it at about the right time. 

But in any case, the data you're suggesting supplying is insufficient for
any host that actually has to deal with times in the (not too far) distant
past - that is, just supplying current offset and next transition is
likely to be fine for (some) embedded hosts, X-terminals, and probably routers
and such, but it is of no use whatever for a workstation/server, where one
of the things that needs to be able to be done is answer questions like
	"That file that was last modified one day in October 3 years ago -
	 was it modified during or outside working hours?"
To answer that you need to know what the DST rules were in October 3 years ago.
What they are this year is useless.   This is why most people who want to
be told the timezone want the ado timezone name that applies, it is the only
way to get useful data (and certainly for me, anything else is completely
useless).

kre

---

From: John Schnizlein <[email-masked]>
Date: Tue, 14 Mar 2006 17:12:05 -0800

> remember to do it at about the right time.

Please help me understand what problem you see.  The correction to UTC 
is a simple unchanging formula, and "about the right time" is usually 
about half a year.  Maybe a simple example would help.

Imagine I get a DHCP lease with the proposed options (time shown as 
interpreted rather than seconds) about now:
Since it is Standard time in Maryland, USA now, TimeOffset = -5, 
nextChange = 2006 Apr 2 2:00:00, NextOffset = -4.  I would get this 
same set of values from a new lease or INFORM any time before 2006 Apr 
2 2:00:00 - the first Sunday in April.  If I have these values when 
that time occurs, my host's  calculation of the wall time would be an 
hour less by application of this (which would work through Summer):

if (UTC(currentTime) < nextChange)
   then wallTime = UTC(currentTime) + TimeOffset
   else wallTime = UTC(currentTime) + NextOffset

My host would then either get a new lease or INFORM sometime before 
2006 Oct 29 2:00:00.  If this does not happen because of some other 
event (possible if my host is running in the same place the whole 
time), the host would have to choose some random (to avoid colliding 
with others with the same degree of stability) time before 2006 Oct 29 
2:00:00 - the last Sunday in October.  Whenever the lease of INFORM 
happens after 2006 Apr 2 2:00:00, the values of the options would be 
TimeOffset = -4, nextChange = 2006 Oct 29 2:00:00, NextOffset = -5.  
These values are good until the 2007 Mar 11 - the second Sunday in 
March (law changed).  Any time between 2006 Oct 29 2:00:00 and 2007 Mar 
11 2:00:00, the values from a new lease or INFORM would be TimeOffset = 
-5, nextChange = 2007 Mar 11 2:00:00, NextOffset = -4.  ...

According to the new US law [ 
http://en.wikipedia.org/wiki/Daylight_saving ] the longer daylight 
saving period would persist unless no energy savings are shown.  
Although the law specifies alternatives, when daylight saving starts 
and stops depends on something we don't know now.  Under these 
conditions the TZ database cannot provide correct adjustments for times 
in the not too far distant future.  To adjust times in the past 
requires the history of arbitrarily changed starts and stops.

> way to get useful data (and certainly for me, anything else is 

Answering historical questions like that should use the best available 
historical records, and they show complex patterns in some locations 
where jurisdictions controlled time.  Of course "during ... working 
hours" depends on local conventions also.

It is also worth noting that the standard abbreviation is ambiguous:  
EST occurs in North America (-5) and in Australia (+10).

IMHO, it is feature creep to impose display and historical context on 
configuration options to determine current time.

John