Re: TIMESTAMP WITHOUT TIME ZONE

> Richard Troy <rtroy(at)ScienceTools(dot)com> 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(at)ScienceTools(dot)com, http://ScienceTools.com/