Subject: Question on calstore current time.

From: [email-masked] (Steve Mansour)
Date: Tue, 11 Dec 2001 16:43:47 -0800

Hey All,

Ages ago, when we decided it would be a good thing for the calstore to
return the current date/time, we came up with this:

     Property Name     Rqd  Type        Description
     CURRENT_DATETIME  Y    DATE-TIME   Current server time. This
     is returned as a local
                                        time and TZID.

We seem to recall that someone had a good reason for returning it as the
server's localtime value and a TZID.  None of us here at the ietf
meeting can remember what that was.

If no one can come up with a good reason for this, we would like to
change it to return the time in UTC.

-Steve

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 11 Dec 2001 19:10:27 -0600

Well the one reason I could initially think of would be as follows:

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 (which should
also be covered to some degree by the Internet Time protocols???) 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.

An alternative would be to say that servers should ALWAYS work in UTC, but
in general servers will be machines that are probably configured for a
particular locale - including for a particular timezone.

It might be clearer if there were TWO separate actions that a calstore could
return - one indicating what the SERVER's locale/default timezone etc were,
and a second for time sync questions? (and/or some indications about how to
formally do timesync stuff?)

This will be a major concern when you are dealing with SYNC issues between
two calstores (such as a local calstore and a server calstore) - the two
servers need to know how to order timestamps - if ALL timestamps were done
in UTC this is not a major problem - just one of detecting if the two
system's clocks are in synch or not, but if objects are timestamped in a
server/application specific local time then ordering them is dependant on
resolving Timezone issues.

Shannon
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Steve Mansour
  Sent: Tuesday, December 11, 2001 6:44 PM
  To: CalSched IETF
  Subject: Question on calstore current time.

  Hey All,

    Property Name     Rqd  Type        Description
    CURRENT_DATETIME  Y    DATE-TIME   Current server time. This is returned
as a local
                                       time and TZID.
  We seem to recall that someone had a good reason for returning it as the
server's localtime value and a TZID.  None of us here at the ietf meeting
can remember what that was.
  If no one can come up with a good reason for this, we would like to change
it to return the time in UTC.

  -Steve

---

From: Doug Royer <[email-masked]>
Date: Tue, 11 Dec 2001 23:29:05 -0700

Steve Mansour wrote:
> We seem to recall that someone had a good reason for returning it as
> the server's localtime value and a TZID.  None of us here at the ietf

It was for small devices that are stupid outside of CAP.
Why not just have date-time returned in the capability?
Also the TZ was the Calendar Properties TZID.

I would not argue if date-time went away.

Lets keep TZID so the CUA can 'know' the TZ of the CS or calendar.
So that a CUA will know when it finds components without
any TZ (localtime) what the localtime is when it sees 10pm.

> change it to return the time in UTC.

That;s fine with me. Lets keep the Calendar - property TZID

---

From: [email-masked] (Steve Mansour)
Date: Wed, 12 Dec 2001 08:27:39 -0800

> It was for small devices that are stupid outside of CAP.

OK. That sounds familiar. Can you explain it further. I still don't get it.

>  Why not just have date-time returned in the capability?

I believe it is returned in the capability.

> That;s fine with me. Lets keep the Calendar - property TZID

Sounds good.

-Steve

---

From: [email-masked] (Steve Mansour)
Date: Wed, 12 Dec 2001 08:27:39 -0800

Sounds good.

-Steve

---

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

> OK. That sounds familiar. Can you explain it further.

It was not (or if it was I dropped it) my idea. I seem to recall it
had to do with device that could not do NTP, but this is the IETF
and we do internet protocols - not random stupid
interfaces (well not on purpose).

So - would debate the point if I could remember the details.