2014-07-10 19:42 GMT-03:00 Sven Van Caekenberghe <s...@stfx.eu>: >> ps: And I guess I now understand the purpose of ZTimestamp :) > > ;-) > > Not only that, there is also ZTimezone with support for the Olsen timezone > database. > > Note that going from local time to UTC and vice versa depends not just on the > TZ but also on the timestamp itself (DST transitions), with possible gaps and > doubles (turn the clock forward/backward), making durations across the DST > transition weird ;-)
Can you expand this? DST can be a complication too, but how to deal with that with current tools/libraries? > Furthermore, a date (or start/end of a day) is also TZ dependent (Saturday > starts earlier/later for me than for you). For example, 'notify me if > something happens on Monday' is trickier than it would seem. I agree. Such calculations should always use a TZ for the client, even when the client is an agent/service, maybe impersonating the real user. > Even though Norbert is right that you can use/mix any/all timezones, the only > way to remain sane, IMHO, is to store everything in UTC and only convert to > local TZ when presenting (this can be really on the client like you suggest > or in Seaside or reporting code on the server). Seems to be the "most recommended way" of dealing with TZ interactions. > You will also need more the just a global setting, you need this per session > ! Sure. Well... I guess I'll have to add ZTimestamp to the supported column types of GLORP tables. If you already have something for Postgres (other than casting TimeStamp or DateAndTime), I'll really appreciate it. Regards! Esteban A. Maringolo
