Re: [HACKERS] datetime regression test fails at daylight savings transitions

Поиск
Список
Период
Сортировка
От Thomas G. Lockhart
Тема Re: [HACKERS] datetime regression test fails at daylight savings transitions
Дата
Msg-id 3634B48B.6A955CB@alumni.caltech.edu
обсуждение исходный текст
Ответ на Re: [HACKERS] datetime regression test fails at daylight savings transitions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] datetime regression test fails at daylight savings transitions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Hmm.  This offers a potential solution, then.  I propose that "day"
> ought to be considered a qualitative time interval, and that
>         'now'::datetime + '1 day'::timespan
> need not yield the same thing as
>         'now'::datetime + '24 hours'::timespan
> Changing things in that way might be infeasible because of backwards
> compatibility constraints, but I think this is what the natural
> interpretation would be.  (Clearly it's what the writer of the 
> datetime regression test was expecting...)

Well, no I wasn't expecting that really :)

I just wanted to be sure to test 'yesterday' and 'tomorrow' behavior,
and didn't want to omit those tests just because they might fail for ~1%
of the year.

Making 'day' a qualitative time is probably possible, just chewing up
another 4 bytes of storage (for 16 bytes rather than 12). But we'll have
to think it through to make sure there aren't other side effects or
other no-so-expected behavior under other conditions.
                   - Tom


В списке pgsql-hackers по дате отправления:

Предыдущее
От: jwieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] How do we find serial types
Следующее
От: jwieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] Last call?