Re: Testing for daylight savings on a GMT server
From: Richard L. Hamilton (Richard.L.Hamilton_at_mindwarp.smart.net)
Date: 11/09/05
- Next message: Richard L. Hamilton: "Re: preparing for sun server crash"
- Previous message: Richard L. Hamilton: "Re: BSD Licensed C++ compiler"
- In reply to: Gordon Burditt: "Re: Testing for daylight savings on a GMT server"
- Next in thread: Gordon Burditt: "Re: Testing for daylight savings on a GMT server"
- Reply: Gordon Burditt: "Re: Testing for daylight savings on a GMT server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 09 Nov 2005 00:10:41 -0000
In article <11moima7v7kak71@corp.supernews.com>,
gordonb.tfskb@burditt.org (Gordon Burditt) writes:
>> All our servers run on GMT, but some external customers run local
>>time and some run on CST, PCT, etc... We run a middleware application
>>that must bend to our customers, so if they expect a file delivered to
>>them at a certain time, or we need to check a file that they deliver to
>>use everyday at 3:00PM I need to make the adjustment in our scripts to
>>look for the file.
>
> And if you've got one customer in China, one customer in France,
> one customer in the USA, one customer in Canada, and one customer
> in Mexico, and they all want the file at 3:00PM their local time,
> you've got a lot more problems than whether daylight savings time
> is in effect, especially if you don't know what time zone your
> customers are in.
>
> Your problem is NOT that you need to know whether daylight savings
> time is in effect. Your problem is that you need to convert from
> one time zone to another. That, of course, requires that you specify
> the time zone involved (*NOT* GMT). One way to do this is to set
> the time zone to the local time zone of a customer (no way to do
> this portably IN C but by POSIX you can set the TZ environment
> variable), and have it convert the local time specified by the
> customer to GMT (using mktime() ). Repeat daily, weekly, or whatever
> to determine the deadline in GMT.
[...]
That's why I've long thought that something like rpc.cmsd ought to record
the local time _and_ time zone that events are scheduled in, so that it
can expand repeating events itself in terms of the time zone in which they
were scheduled. Thus, if I schedule a repeating worldwide event in terms
of my local time, it may shift for DST relative to GMT, and may have both
my DST shifts and the viewer's possibly different DST shifts applied to
it before they see it; that's IMO more intuitive behavior than the current,
which is that it only schedules properly if both clients and rpc.cmsd are
running in the same time zone. Of course, they'd still have to stay in
sync on the rulebase that determined base and DST offsets and DST start
and end dates and times for every given timezone that they might deal with.
Until such a client/server calendar scheduling program does something like
that, or until everyone everywhere schedules cross-timezone events in a
single DST-free timezone (like GMT/UTC), there will be unexpected or
undesirable results.
-- mailto:rlhamil@smart.net http://www.smart.net/~rlhamil Lasik/PRK theme music: "In the Hall of the Mountain King", from "Peer Gynt"
- Next message: Richard L. Hamilton: "Re: preparing for sun server crash"
- Previous message: Richard L. Hamilton: "Re: BSD Licensed C++ compiler"
- In reply to: Gordon Burditt: "Re: Testing for daylight savings on a GMT server"
- Next in thread: Gordon Burditt: "Re: Testing for daylight savings on a GMT server"
- Reply: Gordon Burditt: "Re: Testing for daylight savings on a GMT server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|