Skip site navigation (1) Skip section navigation (2)

Re: Date with time zone

From: Adrian Klaver <aklaver(at)comcast(dot)net>
To: pgsql-general(at)postgresql(dot)org
Cc: Eduardo Piombino <drakorg(at)gmail(dot)com>
Subject: Re: Date with time zone
Date: 2009-11-30 14:46:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
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(at)comcast(dot)net

Adrian Klaver

In response to

pgsql-general by date

Next:From: Robert HaasDate: 2009-11-30 15:23:15
Subject: Re: BUG #5218: Easy strategic feature requests
Previous:From: Howard ColeDate: 2009-11-30 13:39:14
Subject: Re: shared_buffers, work_mem and mantenance_work_mem in Windows

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group