Re: Timestamp Conversion Woes Redux

Well, Oliver and Tom are very deep into things from their perspective,
and I just wanted to offer an opinion from the legions of "app"
developers. My opinion might not be what you expect, since I care less
about compatability than some other things.

What I care about most is that:

1) The conventions for standards-based constructs follow
standards-based rules of engagement, so that if I ever
get a clue about what the standard is, my code will be portable.

2) The code perform like screamin' demons. If setting it to
UNKNOWN slows down all my parameterized query invocations,
I'd rather not see that.

3) If setString() used to work for timestamps and doesn't work
now because of standards compliance changes,
please just tutor me on the correct standards based call to make.

4) If the combined JDBC/backend stuff, when used correctly, is
screwing up timezones, that's mission critical and needs to be fixed.

As far as application portability, I suspect most purveyors of
heavy weight database apps view most any software upgrade, much less a
complete vendor change, to be a "platform port" and so can fix these
little incompatibilities as they debug the rest of their
incompatibilities. (Whether it's adding "WITHOUT OIDS" to my pgsql
CREATE TABLE statements for or "TYPE=INNODB" in futile attempts to get
MySQL to give me transactionally safe tables).

Heck, I'm still using 7.3. I skipped 7.4 because of transactions being
stale on pooled connections, and I've been axiously looking forward to
8.0, but not if my timezones are shot to hell. In all this discussion I
seem to have missed whether they're actually broken or whether I just
need to make a "correct" call.

Thanks for listening, and any further clarifications about my confusions
are welcome.