On 6 April 2011 03:04, Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:
> IMO, the values it gets for the atimestamp (without tz) and atimestamptz (with tz) are sane.
> I dont supply any Calendar in getTimestamp for the "without tz" timestamp so the driver correctly assumes
> we are talking about the local Greek time zone. Correctly 2011-04-05 00:00:00.0 +0300=2011-04-04 21:00:00.0 +0000
> However i dont quite get the results for atime (without tz) and atimetz (with tz):
> For atime it correctly prints the time 00:00:00, but the millis should be -10800000, and in hours should be -3.0.
> For atimetz it incorrectly prints "23:00:00" , but correctly states that the millis=-10800000, and in hours -3.0.
> Shouldn't at least timetz print the same time as in the case with the timestamptz?
What were the Greek timezone rules on Jan 1 1970?
Because that's what it'll be applying (time objects are really just
Date objects based around Jan 1 1970 - it doesn't work very well as
you discovered, but blame JDBC for that one..)
From your results I expect that it was +0200 on Jan 1 1970;
therefore "00:00:00" == Jan 1, 1970, 00:00:00 locally == Dec 31, 1969,
22:00 GMT == -2 hours from the epoch (your 'atime' result)
and "00:00:00+03" == Jan 1, 1970, 00:00:00 +0300 == Dec 31, 1969,
23:00 locally == Dec 31, 1969, 21:00 GMT == -3 hours from the epoch
(your 'atimetz' result)
Oliver