You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Hayo (JIRA)" <ji...@apache.org> on 2007/01/04 15:47:27 UTC
[jira] Created: (LANG-312) DateFormatUtils.format with Timezone
parameter "CET" produces wrong date in summer time 1945 to 1949
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.2, 2.1
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/yyyy", 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/yyyy"); 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/yyyy");
String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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-16 2:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-15 2:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-01 2:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-29 2:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-03 2:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-02 2: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-14 2:00:00 CET until 1946-10-07 3:00:00 CEST
1947-04-06 3:00:00 CET until 1947-10-05 3:00:00 CEST
1948-04-18 2:00:00 CET until 1948-10-03 3:00:00 CEST
1949-04-10 2:00:00 CET until 1949-10-02 3:00:00 CEST
b) High summer time, Advance to CET: 2 hours (GMT+3)
1947-05-11 3:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
c) From 1950 to 1979 no Summer times
d) 1980 to now (most of central europe)
1980-04-06 2:00:00 CET until 1980-09-28 3:00:00 CEST
...
ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone
parameter "CET" produces wrong date in summer time 1945 to 1949
Posted by "Hayo (JIRA)" <ji...@apache.org>.
[ 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/yyyy");
String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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/yyyy", 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/yyyy"); 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/yyyy");
> String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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-16 2:00:00 CET until 1917-09-17 3:00:00 CEST
> 1918-04-15 2:00:00 CET until 1918-09-16 3:00:00 CEST
> 1919 until 1939: No Summer time
> 1940-04-01 2:00:00 CET until 1942-11-02 3:00:00 CEST
> 1943-03-29 2:00:00 CET until 1943-10-04 3:00:00 CEST
> 1944-04-03 2:00:00 CET until 1944-10-02 3:00:00 CEST
> 1945-04-02 2: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-14 2:00:00 CET until 1946-10-07 3:00:00 CEST
> 1947-04-06 3:00:00 CET until 1947-10-05 3:00:00 CEST
> 1948-04-18 2:00:00 CET until 1948-10-03 3:00:00 CEST
> 1949-04-10 2:00:00 CET until 1949-10-02 3:00:00 CEST
> b) High summer time, Advance to CET: 2 hours (GMT+3)
> 1947-05-11 3:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
> c) From 1950 to 1979 no Summer times
> d) 1980 to now (most of central europe)
> 1980-04-06 2:00:00 CET until 1980-09-28 3:00:00 CEST
> ...
> ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Updated: (LANG-312) DateFormatUtils.format with Timezone
parameter "CET" produces wrong date in summer time 1945 to 1949
Posted by "Hayo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hayo updated LANG-312:
----------------------
Issue Type: Improvement (was: Bug)
> 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
>
> DateFormatUtils.format(dt, "dd/MM/yyyy", 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/yyyy"); 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/yyyy");
> String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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-16 2:00:00 CET until 1917-09-17 3:00:00 CEST
> 1918-04-15 2:00:00 CET until 1918-09-16 3:00:00 CEST
> 1919 until 1939: No Summer time
> 1940-04-01 2:00:00 CET until 1942-11-02 3:00:00 CEST
> 1943-03-29 2:00:00 CET until 1943-10-04 3:00:00 CEST
> 1944-04-03 2:00:00 CET until 1944-10-02 3:00:00 CEST
> 1945-04-02 2: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-14 2:00:00 CET until 1946-10-07 3:00:00 CEST
> 1947-04-06 3:00:00 CET until 1947-10-05 3:00:00 CEST
> 1948-04-18 2:00:00 CET until 1948-10-03 3:00:00 CEST
> 1949-04-10 2:00:00 CET until 1949-10-02 3:00:00 CEST
> b) High summer time, Advance to CET: 2 hours (GMT+3)
> 1947-05-11 3:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
> c) From 1950 to 1979 no Summer times
> d) 1980 to now (most of central europe)
> 1980-04-06 2:00:00 CET until 1980-09-28 3:00:00 CEST
> ...
> ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone
parameter "CET" produces wrong date in summer time 1945 to 1949
Posted by "Hayo (JIRA)" <ji...@apache.org>.
[ 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/yyyy", 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/yyyy"); 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/yyyy");
> String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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-16 2:00:00 CET until 1917-09-17 3:00:00 CEST
> 1918-04-15 2:00:00 CET until 1918-09-16 3:00:00 CEST
> 1919 until 1939: No Summer time
> 1940-04-01 2:00:00 CET until 1942-11-02 3:00:00 CEST
> 1943-03-29 2:00:00 CET until 1943-10-04 3:00:00 CEST
> 1944-04-03 2:00:00 CET until 1944-10-02 3:00:00 CEST
> 1945-04-02 2: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-14 2:00:00 CET until 1946-10-07 3:00:00 CEST
> 1947-04-06 3:00:00 CET until 1947-10-05 3:00:00 CEST
> 1948-04-18 2:00:00 CET until 1948-10-03 3:00:00 CEST
> 1949-04-10 2:00:00 CET until 1949-10-02 3:00:00 CEST
> b) High summer time, Advance to CET: 2 hours (GMT+3)
> 1947-05-11 3:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
> c) From 1950 to 1979 no Summer times
> d) 1980 to now (most of central europe)
> 1980-04-06 2:00:00 CET until 1980-09-28 3:00:00 CEST
> ...
> ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Updated: (LANG-312) DateFormatUtils.format with Timezone
parameter "CET" produces wrong date in summer time 1945 to 1949
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henri Yandell updated LANG-312:
-------------------------------
Fix Version/s: 3.0
Assigning to 3.0 for consideration once we've got the 2.3 release out. Hopefully won't be too long a delay before that's done and we can look at this from an enhancement point of view.
> 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/yyyy", 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/yyyy"); 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/yyyy");
> String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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-16 2:00:00 CET until 1917-09-17 3:00:00 CEST
> 1918-04-15 2:00:00 CET until 1918-09-16 3:00:00 CEST
> 1919 until 1939: No Summer time
> 1940-04-01 2:00:00 CET until 1942-11-02 3:00:00 CEST
> 1943-03-29 2:00:00 CET until 1943-10-04 3:00:00 CEST
> 1944-04-03 2:00:00 CET until 1944-10-02 3:00:00 CEST
> 1945-04-02 2: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-14 2:00:00 CET until 1946-10-07 3:00:00 CEST
> 1947-04-06 3:00:00 CET until 1947-10-05 3:00:00 CEST
> 1948-04-18 2:00:00 CET until 1948-10-03 3:00:00 CEST
> 1949-04-10 2:00:00 CET until 1949-10-02 3:00:00 CEST
> b) High summer time, Advance to CET: 2 hours (GMT+3)
> 1947-05-11 3:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
> c) From 1950 to 1979 no Summer times
> d) 1980 to now (most of central europe)
> 1980-04-06 2:00:00 CET until 1980-09-28 3:00:00 CEST
> ...
> ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone
parameter "CET" produces wrong date in summer time 1945 to 1949
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ 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/yyyy", 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/yyyy"); 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/yyyy");
> String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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-16 2:00:00 CET until 1917-09-17 3:00:00 CEST
> 1918-04-15 2:00:00 CET until 1918-09-16 3:00:00 CEST
> 1919 until 1939: No Summer time
> 1940-04-01 2:00:00 CET until 1942-11-02 3:00:00 CEST
> 1943-03-29 2:00:00 CET until 1943-10-04 3:00:00 CEST
> 1944-04-03 2:00:00 CET until 1944-10-02 3:00:00 CEST
> 1945-04-02 2: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-14 2:00:00 CET until 1946-10-07 3:00:00 CEST
> 1947-04-06 3:00:00 CET until 1947-10-05 3:00:00 CEST
> 1948-04-18 2:00:00 CET until 1948-10-03 3:00:00 CEST
> 1949-04-10 2:00:00 CET until 1949-10-02 3:00:00 CEST
> b) High summer time, Advance to CET: 2 hours (GMT+3)
> 1947-05-11 3:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
> c) From 1950 to 1979 no Summer times
> d) 1980 to now (most of central europe)
> 1980-04-06 2:00:00 CET until 1980-09-28 3:00:00 CEST
> ...
> ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone
parameter "CET" produces wrong date in summer time 1945 to 1949
Posted by "Dennis Lundberg (JIRA)" <ji...@apache.org>.
[ 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/yyyy", 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/yyyy"); 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/yyyy");
> String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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-16 2:00:00 CET until 1917-09-17 3:00:00 CEST
> 1918-04-15 2:00:00 CET until 1918-09-16 3:00:00 CEST
> 1919 until 1939: No Summer time
> 1940-04-01 2:00:00 CET until 1942-11-02 3:00:00 CEST
> 1943-03-29 2:00:00 CET until 1943-10-04 3:00:00 CEST
> 1944-04-03 2:00:00 CET until 1944-10-02 3:00:00 CEST
> 1945-04-02 2: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-14 2:00:00 CET until 1946-10-07 3:00:00 CEST
> 1947-04-06 3:00:00 CET until 1947-10-05 3:00:00 CEST
> 1948-04-18 2:00:00 CET until 1948-10-03 3:00:00 CEST
> 1949-04-10 2:00:00 CET until 1949-10-02 3:00:00 CEST
> b) High summer time, Advance to CET: 2 hours (GMT+3)
> 1947-05-11 3:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
> c) From 1950 to 1979 no Summer times
> d) 1980 to now (most of central europe)
> 1980-04-06 2:00:00 CET until 1980-09-28 3:00:00 CEST
> ...
> ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone
parameter "CET" produces wrong date in summer time 1945 to 1949
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ 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/yyyy";
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/yyyy", 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/yyyy"); 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/yyyy");
> String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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-16 2:00:00 CET until 1917-09-17 3:00:00 CEST
> 1918-04-15 2:00:00 CET until 1918-09-16 3:00:00 CEST
> 1919 until 1939: No Summer time
> 1940-04-01 2:00:00 CET until 1942-11-02 3:00:00 CEST
> 1943-03-29 2:00:00 CET until 1943-10-04 3:00:00 CEST
> 1944-04-03 2:00:00 CET until 1944-10-02 3:00:00 CEST
> 1945-04-02 2: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-14 2:00:00 CET until 1946-10-07 3:00:00 CEST
> 1947-04-06 3:00:00 CET until 1947-10-05 3:00:00 CEST
> 1948-04-18 2:00:00 CET until 1948-10-03 3:00:00 CEST
> 1949-04-10 2:00:00 CET until 1949-10-02 3:00:00 CEST
> b) High summer time, Advance to CET: 2 hours (GMT+3)
> 1947-05-11 3:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
> c) From 1950 to 1979 no Summer times
> d) 1980 to now (most of central europe)
> 1980-04-06 2:00:00 CET until 1980-09-28 3:00:00 CEST
> ...
> ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone
parameter "CET" produces wrong date in summer time 1945 to 1949
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ 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/yyyy", 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/yyyy"); 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/yyyy");
> String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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-16 2:00:00 CET until 1917-09-17 3:00:00 CEST
> 1918-04-15 2:00:00 CET until 1918-09-16 3:00:00 CEST
> 1919 until 1939: No Summer time
> 1940-04-01 2:00:00 CET until 1942-11-02 3:00:00 CEST
> 1943-03-29 2:00:00 CET until 1943-10-04 3:00:00 CEST
> 1944-04-03 2:00:00 CET until 1944-10-02 3:00:00 CEST
> 1945-04-02 2: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-14 2:00:00 CET until 1946-10-07 3:00:00 CEST
> 1947-04-06 3:00:00 CET until 1947-10-05 3:00:00 CEST
> 1948-04-18 2:00:00 CET until 1948-10-03 3:00:00 CEST
> 1949-04-10 2:00:00 CET until 1949-10-02 3:00:00 CEST
> b) High summer time, Advance to CET: 2 hours (GMT+3)
> 1947-05-11 3:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
> c) From 1950 to 1979 no Summer times
> d) 1980 to now (most of central europe)
> 1980-04-06 2:00:00 CET until 1980-09-28 3:00:00 CEST
> ...
> ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone
parameter "CET" produces wrong date in summer time 1945 to 1949
Posted by "Dennis Lundberg (JIRA)" <ji...@apache.org>.
[ 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 = -684900000000
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/yyyy", 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/yyyy"); 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/yyyy");
> String cet = DateFormatUtils.format(dt, "dd/MM/yyyy", 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-16 2:00:00 CET until 1917-09-17 3:00:00 CEST
> 1918-04-15 2:00:00 CET until 1918-09-16 3:00:00 CEST
> 1919 until 1939: No Summer time
> 1940-04-01 2:00:00 CET until 1942-11-02 3:00:00 CEST
> 1943-03-29 2:00:00 CET until 1943-10-04 3:00:00 CEST
> 1944-04-03 2:00:00 CET until 1944-10-02 3:00:00 CEST
> 1945-04-02 2: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-14 2:00:00 CET until 1946-10-07 3:00:00 CEST
> 1947-04-06 3:00:00 CET until 1947-10-05 3:00:00 CEST
> 1948-04-18 2:00:00 CET until 1948-10-03 3:00:00 CEST
> 1949-04-10 2:00:00 CET until 1949-10-02 3:00:00 CEST
> b) High summer time, Advance to CET: 2 hours (GMT+3)
> 1947-05-11 3:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
> c) From 1950 to 1979 no Summer times
> d) 1980 to now (most of central europe)
> 1980-04-06 2:00:00 CET until 1980-09-28 3:00:00 CEST
> ...
> ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org