Subject: RE: [lemonade] Re: date-time and delta time [was RE: I-D ACTION:draft-ietf-lemonade-futuredelivery-02.txt]

From: "Eric Burger" <[email-masked]>
Date: Sat, 17 Sep 2005 00:16:20 -0400

The implementation cost is someone needs to know how to convert from
"local time" to UTC.

If we're saying the client does the conversion to UTC, UTC and
delta-time are isomorphic, EXCECPT that UTC *assumes* clock coordination
between client and server.  That is a BIG assumption.  Delta-time always
works.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 16, 2005 11:10 PM
To: Mark Crispin; Eric Burger
Cc: Randall Gellens; [email-masked]; [email-masked]
Subject: Re: [lemonade] Re: date-time and delta time [was RE: I-D
ACTION:draft-ietf-lemonade-futuredelivery-02.txt]

Mark Crispin wrote on 9/16/05 12:02 -0700:
> I don't see the choice as being between delta time and date-time, with
> partisans on both sides.  I see the choice as being between delta time
ONLY
> (thus offending the date-time partisans) and doing BOTH.
>
> Either I'm stupid, or naive, but I simply cannot grasp what is wrong
with
> doing BOTH.

I lean towards doing BOTH as the implementation cost on the server is
not great 
and the client is then free to implement whichever is most convenient.

However, I would not oppose a rough consensus in favor of delta-time
only.

I believe the arguments against date-time only are compelling and I
oppose that 
position.

                - Chris

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Fri, 16 Sep 2005 22:58:07 -0700

> The implementation cost is someone needs to know how to convert from

It all depends upon

> between client and server.  That is a BIG assumption.  Delta-time always

Not if I (the human user) want the message to be delivered at 9AM Tokyo 
time.  In order to derive a delta time for this task, the client must 
know:
  . my local time
  . my offset from UTC
  . Tokyo's offset from UTC

In order to derive the UTC date-time for my request, the client only needs 
to know:
  . Tokyo's time from UTC
and maybe I (the human user) will be required to tell it that.  After all, 
if the time I need is the time in Glennallen, Alaska, it's doubtful that 
many handhelds will know that.

The whole point for allowing a date-time is when the client does NOT have 
coordinated time, and is merely passing on a user's instructions.

As a thought exercise, consider how you will solve this problem:

1) The protocol only allows delta time.
2) The client's clock is not coordinated with the server, and in fact is
    very likely to be wrong since it's telling you that it's 2AM, the sun
    is out, and you're not in the arctic in summer.
3) You need to send a message to be delivered after 2PM New York City time
    today.
4) You'll be fired if it's delivered early or too late.

I think that the people who argue for "delta time only" are thinking 
exclusively about delaying a message for a fixed time, as opposed to 
delaying it until a fixed time.

Nobody is saying that there should be date-time only.  Delta time is 
superior if the user wants a fixed delay interval.  However, delta time 
does not work well if the user wants a fixed time.

We need both on the servers.  If we don't add both on the servers, sooner 
or later people who need the other will add it as an independent 
functionality.

That will result in servers that do one but not the other; and since 
clients can't depend upon what the server has, clients will have to 
implement both.  I really don't think that you want that outcome.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.