On Thursday, June 23, 2011 6:18:18 pm David Johnston wrote:
> Also, is this coercion noted in the documentation anywhere? I looked in
> the obvious locations (Data Type, Function, Appendix B). There should
> probably be something obvious, in the Data Type section, like:
>
> "When a Time Stamp with time zone is created the 'effective' time zone is
> determined and the input value is evaluated according to that time zone.
> If, due to Daylight Savings Time changes, the indicated point-in-time does
> not exist the time component is interpreted as if it were Standard Time and
> then converted to DST (commonly +1 hours) For example: '2007-12-30
> 00:30:00 ART' does not exist because '2007-12-30' is the day of the change
> to DST; the attempt to create a timestamptz with this value will result in
> '2007-12-30 01:30:00 ART' which then is stored as '2007-12-29 10:30:00
> GMT' (ART = GMT - 3). Be aware that during DST-to-STD changeover there
> are no 'missing' times but there is no way to reliably specify whether you
> are dealing with the first or the second occurrence of the time on that
> particular day. The TimeZone specification does not allow one to
> specifically state '1:30AM during DST (1)' or '1:30AM during STD (2)'."
As I understand it, documentation patches are welcomed:)
>
> David J.
--
Adrian Klaver
adrian.klaver@gmail.com