On Sunday 29 November 2009 8:51:33 pm Eduardo Piombino wrote:
>
> Just sharing some thoughts.
> 1. That current "date" datatype is actually an abstract definition of a
> time range. Since it is not localized (put in any time zone), it defines a
> time range going from 00:00:00 hs to 23:59:59.9999 hs of that specific
> non-localized day.
>
> 2. That it does not exist any other abstract "localizable" time range data
> type that i know of, similar to date, such as "month", or even "year".
>
> Because again, if they existed, they would again, need to keep track of
> time zones if they are to be used in multi time zones setups.
>
> I mean, It can be December on a timezone, and January on the next one.
> And the same with the years, it can be 2009 in a time zone, and 2010 in the
> next one.
> The exact same fundamental issue that moved me to bring this subject here.
>
> So I kinda feel the need of specifying a time zone when talking about a
> specific date, a specific month, or a specific year, since all of them
> denote a time range, and that time range can differ according to what time
> zone you are in.
>
> Answer me this question then:
> What day is it now?
> You can't answer me Monday, November 30th.
> You should instead ask me: -Where?
> Because the current day will depend on the location, aka, time zone.
>
> Then, if you want to state a complete reference to specific date, in a
> specific location, you should be able, imo, to specify it along with a time
> zone.
>
Basically you want the time zone info to be informational not binding. The
problem with that is gives the impression that the data type is more complete
then it is i.e the problem with "time with time zone". It also means an extra
level of sanity checks when trying to to do date/time math, to determine
whether the values can actually be operated on. I don't see that happening.
> >
> > --
> > Adrian Klaver
> > aklaver@comcast.net
--
Adrian Klaver
aklaver@comcast.net