On 01/21/2013 07:40 PM, Gavan Schneider wrote:
On Monday, January 21, 2013 at 12:06, Kevin Grittner wrote:
Well, the big problem here is in trying to use either version of
timestamp when what you really want is a date. It will be much
easier to get the right semantics if you use the date type for a
date.
This is the cleanest solution.
And I did not want to imply the following...
Well, another fine assumption shot down:)
Adrian Klaver wrote:
If I was following Gavan correctly, he wanted to have a single
timestamp field to store calender dates and datetimes. In other
words to cover both date only situations like birthdays and
datetime situations like an appointment.
The points raised by Adrain have prompted some more research on my part
and I am intrigued to learn that on one day of the year in many
countries (e.g., Brazil) where daylight conversion happens over midnight
the local-time version of midnight as start of day does not exist.
Basically the last day of unadjusted time ends at midnight and rolls
directly into 01:00:00 the next day (i.e., time 00:00:00 never happens
on this one day). So the current date-> date+time system must already
have some added complexity/overhead to check for this rare special case.
(If not, there's a bug needs fixing!)
If I have learned anything about dealing with dates and times, is that
it is a set of exceptions bound together by a few rules. Every time you
think you have the little rascals cornered, one gets away.
Regards
Gavan Schneider
--
Adrian Klaver
adrian.klaver@xxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
