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 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 right, you need an > > arbitrary assumption in that case. Or we could forbid these timezones > > in timetz input, but that's probably not very helpful. > > After sending my last mail, I concluded that it was in fact me who missed > something and that you were right. I came to the conclusion that you were > talking about the fact that you can specify a timetz also with a date: > > template1=# select '2006-06-01 10:49 America/New_York'::timetz; > timetz > ------------- > 10:49:00-04 > > This date can then be used to infer the timezone: > > template1=# select '2006-03-01 10:49 America/New_York'::timetz; > timetz > ------------- > 10:49:00-05 > > I have updated my patch to do so. Just specifying a timestamp > > select '10:49 America/New_York'::timetz; > > does now return an error. > > Is that a suitable compromise? > > > > Joachim > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(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
