> Richard Troy <rtroy@xxxxxxxxxxxxxxxx> writes: > > See my post from a few minutes ago, but simply put, time/date is at least > > as challenging as money or multibyte character. And, simply put, the > > Postgres implementation of timezone is INSUFFICIENT. > > Really? We do all the things you have listed, and more. AFAICS what > you have described is an outside-the-database reinvention of PG's > semantics for timestamp with time zone. > > regards, tom lane Hi Tom, thanks for the prompt reply... Not much time - just a few moments to reply and then I have to get on with my customer's deliverables... ...ISTM I took the meaning "TIMESTAMP WITH TIMEZONE" literally, while in reality the PG team has implemented the concept but "without timezone" in the database as a part of user data. I confess I never double checked the implementation details thereof as it sounds obvious you're including time zone data in the data stored by the server. Also, of the two RDBMSes in which I personally know the internal implementations of date/time, and of the ones I've talked with the engineers about, none of them get it right or even begin to get it right, so it never occured to me that Postgres would do so much better. Sounds like the PG team has once again thought about the problem from a different perspective and came up with a better answer. That said, nobody has yet assured me that when I give a timestamp I get it back unmolested. As you correctly recall, yes, Science Tools supports five RDBMSes and need to do so as cleanly and consistently as we can, and yes, it's pretty hard to do all the testing, given all the permutations. And, we're in the process of certifying both Ingres (which will make it, I'm sure) and ANTS (which might not). So, seven RDBMS choices... -shrug- I'd appreciate a clean yes/no; From a Java application, throught PG in both directions, the same timestamp comes back that was handed to the JDBC driver so long as it's stored in a "timestamp without time zone" attribute, nomatter neither where on earth the insert/update originates, nor where the select originates? Same bits, yes? Otherwise, "Houston, we've got a problem." Thanks again, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 rtroy@xxxxxxxxxxxxxxxx, http://ScienceTools.com/
