Re: Ease of implementing repeated events 'timeshifts' proposal?

["Mark Horton" <mark@xxxxxxxxxx>]

On Nov 23, 11:05am, Lewis Geer (Exchange) wrote:
> Subject: RE: Ease of implementing repeated events 'timeshifts' proposal?
> Windows 9x and NT keep the time zone information in the registry.

Lewis - could you please clarify?

I think, under this "time shift" proposal, the sending system is going to
have to send out repeating event times in a form something like
	local time
	local zone name
	UTC time or offset
	(date of first shift, date of last shift, hours to be shifted) *

I think this means the implementation needs to know not just what the UTC
equivalent of the local time is, but also the starting and ending dates.

I hunted around my Win 95 and I couldn't find this info, although I must
not know where to look.  Are the start/stop dates for any year in the near
future available through some supported API on Win 95/NT?

As far as I'm aware, the documented APIs on UNIX are in terms of things like
	Convert local time to time_t	(time_t is seconds since 1/1/1970 UTC)
	Convert time_t to local time
	Convert time_t to UTC
	Convert UTC to time_t
	Set/get timezone name
The database with the boundaries exists in /usr/share/lib/zoneinfo but I
don't think there's a documented interface into it.  I suspect that finding
shift start/stop dates would require accessing the database through an
unsupported interface, or duplicating the database inside the application.

	Mark

PS - Why is the text below formatted so ragged? Is there a fix?  I've been
seeing this a lot lately.

> > Over the past few weeks we've been discussing a proposed mechanism for
> > expressing repeated events that span daylight savings 'timeshifts' -
> > namely,
> > encoding an optional list of timeshifts explicitly in the event
> > description.
> > One or two people, however, have expressed concern that in some
> > operating
> > systems platforms it might not be possible for an event creator to
> > figure
> > out the timeshift(s) - i.e., that the event creator software might not
> > be
> > able to find its own daylight savings rules.
> >
> > I'd like to know for sure whether this is really likely to be a problem.
> > While as protocol designers we shouldn't (& can't) bend over backwards
> > to
> > satisfy every possible client OS, it behooves us to make sure that we
> > aren't
> > specifying something that a vary popular OS platform cannot support.
> >
> > The following OS platforms seem to be the most popular/important ones to
> > consider, either now or in the future:
> >         - Windows 3.1
> >         - Windows 95 & NT
> >         - Unix (various flavors)
> >         - Macintosh
> >         - Java API (this is effectively an OS platform)
> >
> > Does anyone know for sure that software written for one or more of these
> > platforms platforms will *not* be able to figure out when its daylight
> > savings timeshifts occur?  (Note that we're talking about what's
> > possible in
> > the *API*, not the user interface.)
> >
> > Personally I think this issue is somewhat of a red herring.  After all,
> > if a
> > node can't figure out its own DST rules, then it's hard to see how it
> > could
> > possibly figure out someone else's (which is what receivers would always
> > need to do if timeshifts weren't encoded).  But I'd like to clear up
> > this
> > issue once and for all...
> >
> >         Ross.
> >
>
>-- End of excerpt from Lewis Geer (Exchange)