Josh Berkus <[EMAIL PROTECTED]> writes: > The reason is simple: our current implementation, which does include DST, > does not include any provision for the exceptions to DST -- such as Arizona
Say what? regression=# set timezone to 'MST7MDT'; SET regression=# select now(); now ------------------------------- 2004-10-25 11:52:47.093538-06 (1 row) regression=# set timezone to 'US/Arizona'; SET regression=# select now(); now ------------------------------- 2004-10-25 10:52:49.441559-07 (1 row) > -- or for the difference between "1 day" and "24 hours". (Try adding "30 > days" to "2004-10-05 10:00 PDT", you'll see what I mean). 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. I think it's orthogonal to the question of how flexible timestamp with time zone needs to be, though. > Nor do I see a way out of this without raising the complexity, and > configurability, level of timezones significantly. 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. > So if we're going to be broken (at least from the perspective of calendar > applications) we might as well be broken in a spec-compliant way. 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly