[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462828
]
Dennis Lundberg commented on LANG-312:
--
The test case fail for me on Windows XP using Sun's JDK 1.4.2_13 and 1.5.0_09.
I did some simple debugging and printed out the underlying int for both the
Calendar and Date objects. Here are the results:
Running org.apache.commons.lang.time.TimeTestSuite
Cal = -684841660985
Date = -6849
I also printed out the expected pattern and the String created by
SimpleDateFormat:
19/04/1948 != 18/04/1948
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
Fix For: 3.0
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be mentioned in the docs, if it is really
intended this way by design.
===
These where the actual summer times in Germany
(http://www.ptb.de/de/org/4/44/441/salt.htm
http://de.wikipedia.org/wiki/Hochsommerzeit#Mitteleurop.C3.A4ische_Sommerzeit)
a) Summer time, Advance to CET (GMT+1): 1 hour (GMT+2)
1916-04-30 23:00:00 CET until 1916-10-01 1:00:00 CEST
1917-04-162:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-152:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-012:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-292:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-032:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-022:00:00 CET until 1945-09-16 2:00:00 CEST
Special: Berlin and sowjet occupied zone:
(1945-05-24) 2:00:00 CET until 1945-11-18
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462845
]
Henri Yandell commented on LANG-312:
What's your machine timezone/locale Dennis?
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
Fix For: 3.0
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be mentioned in the docs, if it is really
intended this way by design.
===
These where the actual summer times in Germany
(http://www.ptb.de/de/org/4/44/441/salt.htm
http://de.wikipedia.org/wiki/Hochsommerzeit#Mitteleurop.C3.A4ische_Sommerzeit)
a) Summer time, Advance to CET (GMT+1): 1 hour (GMT+2)
1916-04-30 23:00:00 CET until 1916-10-01 1:00:00 CEST
1917-04-162:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-152:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-012:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-292:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-032:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-022:00:00 CET until 1945-09-16 2:00:00 CEST
Special: Berlin and sowjet occupied zone:
(1945-05-24) 2:00:00 CET until 1945-11-18 3:00:00 CEST
(1945-05-24) 3:00:00 CET until 1945-09-24 2:00:00 MEHSZ
1946-04-142:00:00 CET until 1946-10-07 3:00:00 CEST
1947-04-063:00:00 CET until 1947-10-05 3:00:00 CEST
1948-04-182:00:00 CET until 1948-10-03 3:00:00 CEST
1949-04-102:00:00 CET until 1949-10-02 3:00:00 CEST
b) High summer
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462850
]
Dennis Lundberg commented on LANG-312:
--
I'm in GMT+1 with locale sv_SE.
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
Fix For: 3.0
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be mentioned in the docs, if it is really
intended this way by design.
===
These where the actual summer times in Germany
(http://www.ptb.de/de/org/4/44/441/salt.htm
http://de.wikipedia.org/wiki/Hochsommerzeit#Mitteleurop.C3.A4ische_Sommerzeit)
a) Summer time, Advance to CET (GMT+1): 1 hour (GMT+2)
1916-04-30 23:00:00 CET until 1916-10-01 1:00:00 CEST
1917-04-162:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-152:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-012:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-292:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-032:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-022:00:00 CET until 1945-09-16 2:00:00 CEST
Special: Berlin and sowjet occupied zone:
(1945-05-24) 2:00:00 CET until 1945-11-18 3:00:00 CEST
(1945-05-24) 3:00:00 CET until 1945-09-24 2:00:00 MEHSZ
1946-04-142:00:00 CET until 1946-10-07 3:00:00 CEST
1947-04-063:00:00 CET until 1947-10-05 3:00:00 CEST
1948-04-182:00:00 CET until 1948-10-03 3:00:00 CEST
1949-04-102:00:00 CET until 1949-10-02 3:00:00 CEST
b) High summer time,
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462483
]
Hayo commented on LANG-312:
---
Thanks for your answer, Henri!
You are right, it is not really a bug in the DateFormatUtils. It was a lack in
understanding the Timezone concept by me and a probably misconception of
java.sql.Date by Sun. I have a proposal at the end, to avoid falling in this
trap.
TimeZone.getDefault().getID() and System.getProperty( user.timezone ) are
Europe/Berlin on all systems we use. Timezone parameter we used for
DateFormatUtils.format is CET. The summer times from 1945 to 1949 obviously
is where CET and Europe/Berlin differ.
Example:
Calendar cal = GregorianCalendar.getInstance(TimeZone.getTimeZone(CET),
Locale.GERMANY);
cal.set(1947, 7, 2);
Now cal.getTimeInMillis(); is not equal (new java.sql.Date(47, 7
,2).getTime()); for default Europe/Berlin
If the Java vm is started with parameter -Duser.timezone=Europe/Berlin,
everybody should be able to reproduce the effect with my code above. (We now
set -Duser.timezone=CET to avoid it in existing deployment).
I admit that with java.util.Date the issue is simply our fault. But, in my
opinion with java.sql.Date the function should be improved. Our buggy real life
code uses java.sql.Date that is returned from the JDBC 2.0 driver for DB2 in a
ResultSet, which is a very common thing to do.
From the documentation of java.sql.Date.
public Date(long date)
Constructs a Date object using the given milliseconds time value. If the given
milliseconds value contains time information, the driver will set the time
components to the time in the default time zone (the time zone of the Java
virtual machine running the application) that corresponds to zero GMT.
So the local time of a java.sql.Date is always 00:00:00.
My proposal for format () is:
if (date instanceof java.sql.Date) {
Calendar cal = GregorianCalendar.getInstance(timeZone, locale);
cal.set(1900 + date.getYear(), date.getMonth(), date.getDate());
} else {
// construct Calendar as already implemented
}
Then there is no way to get the wrong sql date any more. I currently do not see
any drawbacks of this solution.
Regards,
Hayo
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462231
]
Hayo commented on LANG-312:
---
I can almost instantly comment myself:
It really is the java.util.Date vs. java.util.Calendar problem. Creating a
java.util.Date with Calendar does not produce the problem. See code snippet
below:
Calendar c = Calendar.getInstance(TimeZone.getTimeZone(CET),
Locale.GERMANY);
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
c.set(1900 + year, month, day);
java.util.Date dt = c.getTime();
// not: java.util.Date dt = new java.util.Date(year, month,
day);
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
TimeZone.getTimeZone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default: +
def + CET: + cet);
}
}
}
}
Nonetheless i see an issue with DateFormatUtils. While this subtile problem
will persist (and already did cost thousands of Euros only in our project), the
API documentation _must_ state in every param description, that the Date must
be instantiated by java.util.Calendar, not by java.util.Date.
Nicer would be to deprecate all signatures with Date and only allow Calendar
instances as parameter.
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462406
]
Henri Yandell commented on LANG-312:
Thanks for the report Hayo.
I've made a unit test, but it passes (under JDK 1.4 and 1.5; but on OS X).
***
public void testLang312() {
String pattern = dd/MM/;
TimeZone timeZone = TimeZone.getTimeZone(CET);
Locale locale = Locale.GERMANY;
// show Calendar is good
Calendar cal = Calendar.getInstance(timeZone, locale);
cal.set(1948, 3, 19);
assertEquals(19/04/1948, DateFormatUtils.format( cal.getTime(),
pattern, timeZone, locale ) );
Date date = new Date(48, 3, 19);
// test JDK
java.text.SimpleDateFormat sdf = new
java.text.SimpleDateFormat(pattern, locale);
sdf.setTimeZone(timeZone);
assertEquals(19/04/1948, sdf.format( date ) );
// test Commons
assertEquals(19/04/1948, DateFormatUtils.format( date, pattern,
timeZone, locale ) );
}
***
Does that look right to you, and more importantly does it fail on your machine?
It's checked in - so the nightly build (Linux + JDK 1.5) will hit it too.
DateFormatUtils sits on top of FastDateFormat, but there's not a huge amount in
there so I'm quite interested in whether the same issue exists in
java.text.SimpleDateFormat.
We've a release heading out soon (one other blocker issue besides this one), so
hopefully we can get to the bottom of this quickly and get the
deprecations/javadoc warnings out there quickly if need be.
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462407
]
Henri Yandell commented on LANG-312:
(copying you with the quick reply to oneself :) )
The only difference I know of between a new Date and a Calendar.getDate is that
the latter has the TimeZone from the Calendar. So this might imply that the
TimeZone being passed in is not correctly used somewhere.
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be mentioned in the docs, if it is really
intended this way by design.
===
These where the actual summer times in Germany
(http://www.ptb.de/de/org/4/44/441/salt.htm
http://de.wikipedia.org/wiki/Hochsommerzeit#Mitteleurop.C3.A4ische_Sommerzeit)
a) Summer time, Advance to CET (GMT+1): 1 hour (GMT+2)
1916-04-30 23:00:00 CET until 1916-10-01 1:00:00 CEST
1917-04-162:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-152:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-012:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-292:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-032:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-022:00:00 CET until 1945-09-16 2:00:00 CEST
Special: Berlin and sowjet occupied zone:
(1945-05-24) 2:00:00 CET until 1945-11-18 3:00:00 CEST
(1945-05-24) 3:00:00 CET until 1945-09-24 2:00:00 MEHSZ
1946-04-142:00:00 CET until 1946-10-07 3:00:00 CEST
1947-04-063:00:00 CET
