Patch applied. Thanks.
---
Joachim Wieland wrote:
> On Thu, Jun 01, 2006 at 12:35:44PM -0400, Tom Lane wrote:
> > Joachim Wieland <[EMAIL PROTECTED]> writes:
> > > I'm talking about the timetz type that does not carry a da
: Thursday, June 01, 2006 11:36 AM
Subject: Re: [PATCHES] TODO-Item: full timezone names
On Thu, Jun 01, 2006 at 12:35:44PM -0400, Tom Lane wrote:
Joachim Wieland <[EMAIL PROTECTED]> writes:
> I'm talking about the timetz type that does not carry a date. So you
> don't
>
On Thu, Jun 01, 2006 at 12:35:44PM -0400, Tom Lane wrote:
> Joachim Wieland <[EMAIL PROTECTED]> writes:
> > 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 witho
"Kevin McArthur" <[EMAIL PROTECTED]> writes:
> My vote is that you guys drop timetz completely.
I can already give you the final score on that one:
SQL standard 1, Kevin 0
The problem here is the same old bugaboo that the standard pretends
daylight-savings time doesn't exist. So we are i
TECTED]>
Cc:
Sent: Thursday, June 01, 2006 10:31 AM
Subject: Re: [PATCHES] TODO-Item: full timezone names
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"
Joachim Wieland <[EMAIL PROTECTED]> writes:
> 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?
Oh, doh, I managed to miss that detail. Yeah, you're
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
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 p
Hi,
I propose the appended patch for the Todo item:
o Allow timezone names in SQL strings, '2006-05-24 21:11
Americas/New_York'::timestamptz
I changed the ParseDateTime function as well as DecodeDateTime to support
those timezones in timestamps and DecodeTimeOnly to support it
