[Ietf-calsify] Re: DURATION and PERIOD - proposal

Reinhold Kainhofer reinhold at kainhofer.com
Fri Apr 15 11:47:19 PDT 2005


Am Freitag, 15. April 2005 20:30 schrieb Doug Royer:
> Reinhold Kainhofer wrote:
> >>Finish reading that email. It addressed that issue.
> >
> > No, you basically say that 1D should always mean 24H. And you also say
> > that if the user expects the event to end at the same time on the next
> > day in his timezone, the user's expectations are wrong...
>
> I said no such thing and I have no clue why you think I did.

Implicitly, see below.

> I said when you do the math in UTC - everything works. A day
> is never 25 or 23 hours, 

Huh? Sure, for me (as a user) March 27, 2004, is only 23 hours long (in Europe 
where DST starts at that date).
You say that by definition a day is 24 hours, and from this, of course the end 
time is not always the same. 
The user, however, thinks differently (see below). For a typical user 1D means 
same time on the next day. Now you say, that the result with the 24 hours 
duration is always correct, and although the user understands a duration of 1 
day differently and expects a different result.

Basically, it boils down to two different definitions of one day. Does a 
duration of 1 day mean:
-) one day (same time, different date) in absolute time coordinates, but not 
necessarily in the time zone of the event? This definition is equivalent to a 
duration of 24 hours. The end time in the user's local time is not always the 
same.
-) one day (same time, different date) in the user's local time? The duration 
is not constant, but the end time is the same for all occurences.

You think using the first definition, the user (intuitively) thinks in terms 
of the second definition.

> it just appears that way when you 
> look at a clock that was changed.

Yes, but 
1) the users think in time and date separated, so one day duration means: 
Increase the date by one, leave the time untouched.
2) the user doesn't think in absolute time coordinates. Almost all users think 
relative to that clock, which was changed. 

Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/37fe7697/attachment-0001.bin


More information about the Ietf-calsify mailing list