On Wednesday 20 July 2005 11:40, Christian Cryder wrote:
> b) sending the data across as millisecs value, rather than
> flattening to a Timestamp string? That way to could avoid the
> toString() issues mentioned above, plus it'd probably be faster to
> reconsitute from millis on the server than by parsing a timestamp
> string anyways.
I learned all sorts of fascinating things by reading this thread:
http://forum.java.sun.com/thread.jspa?messageID=2813701
For example:
| $ export TZ=Europe/London
| $ date +%s -d '19981231 23:59:00'
| 915148740
| $ date +%s -d '19990101 00:00:00'
| 915148800
|
| We can see here that the duration of the last minute in 1998 was 60
| seconds.
|
| The more or less experimental time zones prefixed by "right/"
| accounts for leap seconds:
|
| $ export TZ=right/Europe/London
| $ date +%s -d '19981231 23:59:00'
| 915148761
| $ date +%s -d '19990101 00:00:00'
| 915148822
|
| We see here that the same last minute was 61 seconds long.
|
| The implementation of Java by Sun does not retrieve the leap
| seconds info from the C library.
|
| As leap second support seems not to have been implemented yet,
| every minute in Sun's Java seems to be 60 seconds long.
|
| But there is no guarantee it won't change in the future, as
| permitted in the documentation, and other implementations of Java
| can be different, too.
Based on this, I get the vague impression that Java's interpretation
of milliseconds since epoch may differ from PostgreSQL's interpretation
of the same.