Laconic2 wrote:
> "Rok Debeljak" <rok.debeljak_at_milenij.si.remove> wrote in message
> news:Ru2ld.5529$F6.1282471_at_news.siol.net...
>
>>>Here are the two times:
>>
>> >
>> > 2004.11.11 24:00
>> > 2005.11.12 00:00
>> > ...
>> > If a computation happened to result in 2004.11.11 24:00, I would
>>want it to
>> > convert it to 2005.11.12 00:00. And I would call this final step
>>
>>One year up or down does not really make any difference for a comparator
>>that really understands what we are talking about ;-)
>>
>>Rokson
>
>
>
> Ouch!!!! Of all the typos I've ever made, this is the worst. I don't know
> how I missed it. My proofreading skills are going down the drain!
>
> Let me try the whole thing over again, corrected:
>
>
>
>>According to ISO, we can assign the value 0000 or 2400 to midnight. Let's
>>look at another time, say 2 PM, or 1400 . Do we assign two values to 1400?
>
>
>
> Believe it or not, this is a problem in "normalization". Not "data
> normalization" as we ordinarily speak of it in database discussions, but
> normalization nonetheless.
>
> Let's say that we are given two times, and asked whether they are equal or
> not.
>
> Here are the two times:
>
> 2004.11.11 24:00
> 2004.11.12 00:00
>
> The above form is for illustration purposes only.
>
> Now a naive comparator would answer the question "no". But a comparator
> that really understands what we are talking about
> might take a closer look, and come up with the answer: "yes". I like the
> answer "yes", myself, better.
>
> In fact, I would like the "time type engine" whenever it's done some
> calculation on time, (like adding an "interval" to a "base time") to
> perform one final step, before delivering the result to the outside world.
> If a computation happened to result in 2004.11.11 24:00, I would want it
> to
> convert it to 2004.11.12 00:00. And I would call this final step
> "normalizing the result".
>
> Once the results of a computation have been "normalized" , a naive
> comparator
> can test for equality by just comparing the representations. Right?
>
>
>
>
>
Actually, IMO, this makes a strong argument for storing times
internally as a certain number of "clock-ticks" since an "epoch".
Then the question reduces itself as to how to represent the
instance of time which is "midnight" - 2400 hours or 0000 hours?
NPL
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Received on Fri Nov 12 2004 - 12:48:36 CST
