Re: Demo: Modelling Cost of Travel Paths Between Towns
Date: Fri, 12 Nov 2004 10:03:46 -0500
Message-ID: <fKydnZV5S_xLTQncRVn-pw_at_comcast.com>
"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
The above form is for illustration purposes only.
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
Once the results of a computation have been "normalized" , a naive
comparator
2004.11.12 00:00
convert it to 2004.11.12 00:00. And I would call this final step
"normalizing the result".
can test for equality by just comparing the representations. Right?
Received on Fri Nov 12 2004 - 16:03:46 CET