Re: Timestamp Conversion Woes Redux

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.