pgjdbc/pgjdbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feedFrom: bokken (@bokken) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: Re: [pgjdbc/pgjdbc] issue #1325: Additional jsr 310 support
Date: Thu, 15 Nov 2018 14:06:16 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
`Timestamp` as a data type is not bound the the jvm time zone. The jdbc api for setTimestamp and getTimestamp have specified the use of the default timezone when no Calendar is provided. The `toString` implementation of `java.util.Date` (and thus java.sql.Timestamp) use the timezone of the jvm when constructing a String.
The example you give show both java.sql.Timestamp and java.time.Instant having the same behavior, which was my point of them being the same data type.
> I feel allowing these kinds of conversions will further perpetuate the subtle time zone bugs that people are complaining about with the existing java.sql and java.util.Date APIs.
I certainly understand that there are challenges with the TIMESTAMP datatype and that users should be encouraged to use TIMESTAMPTZ. But should this project "force" that by limiting the support for TIMESTAMP with the introduction of new data types?
view thread (25+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: github://pgjdbc/pgjdbc
Cc: [email protected], [email protected]
Subject: Re: [pgjdbc/pgjdbc] issue #1325: Additional jsr 310 support
In-Reply-To: <<[email protected]>>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox