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@gmail.com
