JDBC Driver and timezones
in [Java Programming]
|
Prev: [Press Release] WANdisco Gives Back to the Subversion Community
Next: WANdisco Gives Back to the Subversion Community
From: Lew on 19 May 2010 11:33 Kris Jurka >> I think the problem is that the Java specification for java.sql.Time >> requires that the date portion be filled in with 1970-01-01. So when >> trying to determine the zone shift to apply when printing it out, it is >> checking with that date instead of today's date as you are expecting. >> >> When reading a timetz value in, we don't need to determine what the zone >> shift is, it's explicit, so in this case we shift by the explicit DST >> amount. When printing it back out, the original zone offset has been >> discarded and we shift by the non-DST amount because the date 1970-01-01 >> doesn't use DST. I think we'd like to be able to override the >> getTimezoneOffset value for the Time object, but there's no easy way to >> do that without creating our own PgTime object. On 05/19/2010 06:43 AM, John Lister wrote: > Hi, I spotted an issue regarding Daylight savings and timezones a while > ago that affected UK times so it may be possible that it does the same > in German ones. From memory - essentially the driver uses the epoch date > to work out DST which unfortunately coincides with a year (1970) when > the UK temporarily changed its DST rules. This issue came up in pgsql.interfaces.jdbc and it seemed worth bringing into the wider Java world since it's not Postgres-specific. The problem is that java.sql.Time values are date-agnostic so might not reflect the intended DST offset when referencing times relevant to "now". This might be worth a bug report, or perhaps the problem is intractable and requires the explicit workaround that the database folks find they must use. Perhaps the new date/time libraries will address this somehow. Opinions or assessments? -- Lew |