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,