On Thu, Jun 01, 2006 at 11:00:12AM -0400, Tom Lane wrote:
> Joachim Wieland <[EMAIL PROTECTED]> writes:
> > With a timetz it's more tricky, because "America/New_York" does not specify
> > a timezone offset by itself, this could change due to daylight savings time
> > for example. So my idea was to apply whatever offset is valid in this region
> > at the moment of parsing the string representation.

> You can't be serious.  The correct interpretation of
>       '2006-06-01 10:49 America/New_York'
> has to be 10:49 in whatever time was then in use in New York.  Not when
> you read the string.

I'm talking about the timetz type that does not carry a date. So you don't
know if daylight savings time is active or not. How would you interpret the
full timezone in this case without a date?


Joachim

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to