On Sun, 6 May 2001, Abhijit Menon-Sen wrote:

> On 2001-05-06 11:15:37, [EMAIL PROTECTED] wrote:
> > 
> > > Now is about 20010506T073000+0530 localtime [...]
> > 
> > Is this the fairly standard (or at least conventional) way to deal
> > with [timezones]?
> 
> The "Z" or [+-]offset scheme I described is the ISO 8601 way to deal
> with it. As far as I know, the conventional method to handle (named)
> time zones is the Olson database <URL:ftp://elsie.nci.nih.gov/pub/>.

On Unix systems. Not all platforms that Perl runs on have access to
an Olson database. 

> Shane -- I don't know how to handle DST. RFC 2445 and ISO 8601 both
> ignore it totally (which is the only sane thing to do :).
> 
> Ideas? How would you handle it today?

Others far wiser than I have spent many electrons on the subject:

http://www.imc.org/ietf-calendar/mail-archive/msg07044.html
(This is the infamous "Does 1 day == 24 hours?" thread.)

I think that RFC2445 trusts systems that speak it to do the Right
Thing. The problem here, from an implementation perspective, is that
the various platforms Perl runs on are likely to have varying ideas
of what the Right Thing is. 

Here's a thought experiment: Someone sends me a message saying that
a 2-hour conference call happens starting at 1am my time. After
reciting the litany against meetings, I'd prepare myself to be on
the phone for 2 hours. My computer knows about the meeting, and it
logically assumes that a 2-hour meeting starting at 1 will end at 3. 
It's unaware of DST. Here's its logic process:

---------------------------------------------------------------
1am EST -  begin the conference call. Start a timer for 2 hours.

1:45 EST - oh, look, we're going from standard time to daylight
time. I'll reset my clock to 2:45 EDT.

2:45 EDT - there are 15 minutes left in the meeting.

3:00 EDT - Hm. My meeting timer says I've been in this meeting for 2
hours. Pop up a message telling Shane the meeting's over.
[Which I ignore, because I've only been on the phone for 1 hour.
At 4:00am by my computer's clock, I get off the phone.]
--------------------------------------------------------------

I have no idea how my local time interacts with UTC/Greenwich time.  
Since DST is a political choice, I have no way of knowing whether
UTC (or any other timezone) uses DST, and if it does, what day and
localtime that DST starts. I don't think that calculating times in
UTC is going to make this problem any easier.

I'd love to just throw up my hands and trust the computer, but I
have a nagging feeling that something's not quite right if I do
that. The above example is as close as I can come right now to
explaining why.

srl
-- 
Shane R. Landrum         [EMAIL PROTECTED] 
we generate our own light to compensate for the lack of light from above -AD
GPG public key: http://cs.smith.edu/~slandrum/srl_pgpkey.txt

Reply via email to