org.w3c.util.DateParser timezone bug

[reposting this since it didn't make it to the list. Did send Yves Lafon 
a copy at the time.]

-------- Original Message --------
Subject: org.w3c.util.DateParser timezone bug
Date: Fri, 25 Mar 2005 16:47:22 +0100
From: Menno Jonkers <lists_w3_org@jonkers.com>
To: www-jigsaw@w3.org

Hi,

I'm under the impression that the getCalendar() method in
org.w3c.util.DateParser handles the time zone the wrong way around.

In the example at [1] it is explained how these ISO dates both
correspond to November 5, 1994, 8:15:30 am, US Eastern Standard Time:

  1994-11-05T08:15:30-05:00
  1994-11-05T13:15:30Z

Yet when running these through DateParser.parse() I get:

  Sat Nov 05 04:15:30 CET 1994
  Sat Nov 05 14:15:30 CET 1994

These differ (and are in my CET zone, but that shouldn't matter).

The problem seems that at the end of the getCalendar() method the time
zone is added to the UTC calendar instance. But when going /to/ UTC it
should be subtracted.

Reversing the signs as shown in the (local) patch below, results in:

  Sat Nov 05 14:15:30 CET 1994
  Sat Nov 05 14:15:30 CET 1994

as well as sensible behavior for a lot of other dates.

Regards,

Menno Jonkers


[1] http://www.w3.org/TR/1998/NOTE-datetime-19980827


diff -u -u -r1.1 DateParser.java
--- DateParser.java     19 Jan 2005 14:25:12 -0000      1.1
+++ DateParser.java     25 Mar 2005 15:46:28 -0000
@@ -144,11 +144,11 @@
                     throw new InvalidDateException("Missing minute field");
                 }
                 if (plus) {
-                   calendar.add(Calendar.HOUR, tzhour);
-                   calendar.add(Calendar.MINUTE, tzmin);
-               } else {
                     calendar.add(Calendar.HOUR, -tzhour);
                     calendar.add(Calendar.MINUTE, -tzmin);
+               } else {
+                   calendar.add(Calendar.HOUR, tzhour);
+                   calendar.add(Calendar.MINUTE, tzmin);
                 }

Received on Wednesday, 11 May 2005 10:57:35 UTC