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