Subject: RE: Question on calstore current time.

From: "John Stracke" <[email-masked]>
Date: Wed, 12 Dec 2001 13:07:23 -0500

>Say you have a server dealing with a number of events and actions
>(such as VALARMS) and your CUA needs to provide an answer to you
>about when your SERVER will take a particular action.
> 
>Just knowing what "time" in UTC that the server thinks it is
[...]
> only tells you if the server is off in terms of minutes
>and seconds - it doesn't tell you what "timezone/local" the server
>itself is working in.

The server's concept of its own timezone is irrelevant.  All that matters 
is the timezone specified in the VALARM; that tells the server how to 
convert to/from UTC to render the alarm correctly.

I suppose the server's OS could (a) be maintaining its own clock in local 
time, and (b) have a bug in its timezone conversions, so that it tells the 
server application the wrong UTC time.  However, I don't think we really 
need to support servers chipped out of flint by Homo erectus.

/===============================================================\
|John Stracke                   |Principal Engineer             |
[email-masked]  |Incentive Systems, Inc.        |
|http://www.incentivesystems.com|My opinions are my own.        |
|===============================================================|
|"Power corrupts; Powerpoint corrupts absolutely." -- Vint Cerf |
\===============================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 12 Dec 2001 12:42:31 -0600

John,

Are VALARMS required to specify time in a TIMEZONE or UTC format? I can
clearly see many use cases for VALARMS where local time would be very
desirable - i.e. an alarm that performs some action prior to my lunch time
each day. Under a number of cases this would then vary in behavior  in
accord with the server's own view of "local time" - i.e. defined by the
server's choice of timezone.

The point being that servers may reasonably be doing actions in the case of
VALARMS, and users (and their CUA) would need to know how the server views
the world.

The other use case being when synchronization actions are taking place -
i.e. actions requiring an interpretation of DTIME (i.e. timestamps on
objects) - if those timestamps are in local time (which perhaps they
"shouldn't" be... but is it a MUST that they are in UTC?)

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Wednesday, December 12, 2001 12:07 PM
To: CalSched IETF
Subject: RE: Question on calstore current time.

[...]

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Dec 2001 15:40:00 -0700

"Shannon J. Clark" wrote:

> Are VALARMS required to specify time in a TIMEZONE or UTC format? 

Both PLUS with a time not in UTC and without a TIMEZONE.
As in December 31st at 12:59:59 - New Year. It is not
in any time zone or UTC. Yet I can make a sharable
VEVENT with that data in it that is valid in all time zones.

> "shouldn't" be... but is it a MUST that they are in UTC?)

(DTSTAMP not DTIME?)

What doe RFC-2445 say?

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 12 Dec 2001 17:31:51 -0600

Doug,

Well RFC 2445 appears to have this handled fairly reasonably:

To quote from the description of the DTSTAMP property:

   Description: The value MUST be specified in the UTC time format.

So all processes that use the DTSTAMP (to sort objects for example), or use
the LAST-MODIFIED or CREATED (?) properties will be using UTC to sort and
handle them.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Doug Royer
Sent: Wednesday, December 12, 2001 4:40 PM
To: [email-masked]
Subject: Re: Question on calstore current time.

(DTSTAMP not DTIME?)

What doe RFC-2445 say?