TLDR: a timezone is mostly a property of the presentation, and rarely should be saved as a part of the data. l-t currently doesn't support a timestamptz class, and probably it shouln't either. maybe the postgres - local-time integration could introduce a new timestamptz class, but l-t shouldn't know anything about it.
> > this needs to be cleaned up in local-time before a better postgres > > integration can be written. > > Can you explain what those issues are in the context of a postgres > integration? I went through the l-t TODO file but I am unable to > figure out which ones you are concerned about. hrm... i may be mis-remembering stuff, it's been a while. sorry if i wasted your time! i've spent a few minutes looking at the code and the TODO, and i couldn't identify any serious issues. all i remember is that, at some point a few years ago, we had to maintain a fork of local-time with our codebase that uses postgres and heavily relies on timestamps. maybe what i said is obsolete by now, because the major issue was that at some point a l-t timestamp structure (wrongly) included a timezone. a timezone is only a parameter of the printing and parsing functions of timestamps, that turn timestamps into a humanly understandable presentation (in the context of a calendar system and a timezone). i fixed that years ago, which was quite an overhaul of local-time. some issues remained for which we had to sustain a fork, but i think they were not fundamental as the above mentioned confusion. > Also, are there any issues with parsing a timestamptz into a > LOCAL-TIME:TIMESTAMP? there are some nuisances due to the wrong understaing of timestamptz in postgres (timezones are irrelevant until the point you want to turn timestamps into a humanly readable form, or parse them from a humanly readable form). it's all fine when you parse a postgres timestamptz into a l-t timestamp. l-t will properly construct that point of time into a l-t timestamp, but the timezone part will be lost/discarded, so you cannot really produce a timestamptz from a l-t timestamp, unless you separately keep track of the timezone (and hope that postgres is using the same timezone database, because the politicians keep changing the summer time laws and stuff). maybe %split-timestring in l-t could be patched to not only return (offset-hour offset-minute), but something more complex to better denote a timezone. but basically timestamptz is a fauly idea, it shouldn't exist. everything should explicitly deal with a separate timestamp and a timezone designator -- *if* a timezone designator is needed, which is rarely a case. as a user, i want to see a timestampt presented to me in my preferred timezone, or in the timezone derived from the context the timestamp is presented in (i.e. the time of a location based meeting should be printed in the timezone relevant to the location; and for an international conference call, in everyone's local timezone). hth, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “All authority of any kind, especially in the field of thought and understanding, is the most destructive, evil thing. Leaders destroy the followers and followers destroy the leaders. You have to be your own teacher and your own disciple. You have to question everything that man has accepted as valuable, as necessary.” — Jiddu Krishnamurti (1895–1986), 'Freedom from the Known'
