Tom, > regression=# set timezone to 'US/Arizona'; > SET > regression=# select now(); > now > ------------------------------- > 2004-10-25 10:52:49.441559-07
Wow! When did that get fixed? How do I keep track of this stuff if you guys keep fixing it? ;-) Of course, it would be very helpful if the result above could display "Arizona" instead of the non-specific "-07", but I'm pretty sure that's already a TODO. > This is the point about how interval needs to treat "day" as different > from "24 hours". I agree with that; the fact that it's not done already > is just a reflection of limited supply of round tuits. Well, when I first brought up the issue (2001) I was shot down on the basis of spec-compliance, since SQL92 recognizes only Year/Month and Day/Hour/Minute/etc. partitions. Glad it's up for consideration again. Come to think of it, it was Thomas Lockhart who shot down the idea of fixing Interval, and he's retired now ... > This does not seem to me to be an argument why timestamp with time zone > ought to be incapable of dealing with DST-aware time zones. That simply > guarantees that calendar apps won't be able to use the datatype. If > they still can't use it when it can do that, then we can look at the > next blocking factor. That's definitely a progressive attitude .... pardon me for being pessimistic. > I have not said that we can't comply with the spec. I have said that > our ambitions need to be higher than merely complying with the spec. Hmmm ... well, does the spec specifically prohibit DST, or just leave it out? -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
