> 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
Laconic2 wrote:
> "Alan" <alan_at_erols.com> wrote in message
> news:2vhas0F2lnpsgU1_at_uni-berlin.de...
>
>>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
> normalizations 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
> 2005.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 2005.11.12 00:00. And I would call this final step
> "normalizing the result".
>
> Once the results of a computaion have been "normalized" , a naive comparator
> can test for equality by just comparing the representations. Right?
>
>
>
>
Received on Fri Nov 12 2004 - 07:01:28 CST
