[
https://issues.apache.org/jira/browse/LANG-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14389931#comment-14389931
]
Bruno P. Kinoshita edited comment on LANG-1104 at 4/1/15 3:55 AM:
------------------------------------------------------------------
In 1900, Sao Paulo was 3 hours, 6 minutes, and 28 seconds behind GMT. The ZZ
format will encode that difference as "-0306", which introduces a 28 seconds
difference in the round trip. The ZZ format cannot be considered a high
fidelity format for historic time in certain time zones. (Atlantic/Reykjavik
happened to be 1:27:48 behind GMT in 1900)
A couple of instructive unit tests which only use JRE classes:
{noformat}
@Test
public void test1104_a() throws ParseException {
TimeZone tzSaoPaulo = TimeZone.getTimeZone("America/Sao_Paulo");
Locale usLocale = Locale.US;
final SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd/ZZ",
usLocale);
sdf.getCalendar().setTimeZone(tzSaoPaulo);
final Calendar cal = Calendar.getInstance(tzSaoPaulo, usLocale);
cal.clear();
cal.set(Calendar.MONTH, 1);
cal.set(Calendar.DAY_OF_MONTH, 10);
cal.set(Calendar.YEAR, 1900);
final Date expected = cal.getTime();
String formattedDate = sdf.format(expected);
Assert.assertTrue(formattedDate.endsWith("-0306")); // Surprise!
Historically, Sao Paulo is 3 hours and 6 minutes behind GMT
final Date actual = sdf.parse(formattedDate);
Assert.assertEquals(tzSaoPaulo, sdf.getCalendar().getTimeZone());
long diff = TimeUnit.SECONDS.toMillis(28); // Surprise!! In
February of 1900, Sao Paulo was 3 hours, 6 minutes, and 28 seconds behind GMT
Assert.assertEquals(diff, expected.getTime() - actual.getTime());
}
@Test
public void test1104_b() throws ParseException {
TimeZone tzSaoPaulo = TimeZone.getTimeZone("America/Sao_Paulo");
Locale usLocale = Locale.US;
final Calendar cal = Calendar.getInstance(tzSaoPaulo, usLocale);
cal.clear();
cal.set(Calendar.MONTH, 1);
cal.set(Calendar.DAY_OF_MONTH, 10);
cal.set(Calendar.YEAR, 1900);
final Date expected = cal.getTime();
TimeZone tzEratzSaoPaulo = TimeZone.getTimeZone("GMT-0306");
final Calendar eratz = Calendar.getInstance(tzEratzSaoPaulo, usLocale);
eratz.clear();
eratz.set(Calendar.MONTH, 1);
eratz.set(Calendar.DAY_OF_MONTH, 10);
eratz.set(Calendar.YEAR, 1900);
final Date actual = eratz.getTime();
long diff = TimeUnit.SECONDS.toMillis(28); // Surprise!! In
February of 1900, Sao Paulo was 3 hours, 6 minutes, and 28 seconds behind GMT
Assert.assertEquals(diff, expected.getTime() - actual.getTime());
}
{noformat}
was (Author: [email protected]):
In 1900, Sao Paulo was 3 hours, 6 minutes, and 28 seconds behind GMT. The ZZ
format will encode that difference as "-0306", which introduces a 28 seconds
difference in the round trip. The ZZ format cannot be considered a high
fidelity format for historic time in certain time zones. (Atlantic/Reykjavik
happened to be 1:27:48 behind GMT in 1900)
A couple of instructive unit tests which only use JRE classes:
@Test
public void test1104_a() throws ParseException {
TimeZone tzSaoPaulo = TimeZone.getTimeZone("America/Sao_Paulo");
Locale usLocale = Locale.US;
final SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd/ZZ",
usLocale);
sdf.getCalendar().setTimeZone(tzSaoPaulo);
final Calendar cal = Calendar.getInstance(tzSaoPaulo, usLocale);
cal.clear();
cal.set(Calendar.MONTH, 1);
cal.set(Calendar.DAY_OF_MONTH, 10);
cal.set(Calendar.YEAR, 1900);
final Date expected = cal.getTime();
String formattedDate = sdf.format(expected);
Assert.assertTrue(formattedDate.endsWith("-0306")); // Surprise!
Historically, Sao Paulo is 3 hours and 6 minutes behind GMT
final Date actual = sdf.parse(formattedDate);
Assert.assertEquals(tzSaoPaulo, sdf.getCalendar().getTimeZone());
long diff = TimeUnit.SECONDS.toMillis(28); // Surprise!! In
February of 1900, Sao Paulo was 3 hours, 6 minutes, and 28 seconds behind GMT
Assert.assertEquals(diff, expected.getTime() - actual.getTime());
}
@Test
public void test1104_b() throws ParseException {
TimeZone tzSaoPaulo = TimeZone.getTimeZone("America/Sao_Paulo");
Locale usLocale = Locale.US;
final Calendar cal = Calendar.getInstance(tzSaoPaulo, usLocale);
cal.clear();
cal.set(Calendar.MONTH, 1);
cal.set(Calendar.DAY_OF_MONTH, 10);
cal.set(Calendar.YEAR, 1900);
final Date expected = cal.getTime();
TimeZone tzEratzSaoPaulo = TimeZone.getTimeZone("GMT-0306");
final Calendar eratz = Calendar.getInstance(tzEratzSaoPaulo, usLocale);
eratz.clear();
eratz.set(Calendar.MONTH, 1);
eratz.set(Calendar.DAY_OF_MONTH, 10);
eratz.set(Calendar.YEAR, 1900);
final Date actual = eratz.getTime();
long diff = TimeUnit.SECONDS.toMillis(28); // Surprise!! In
February of 1900, Sao Paulo was 3 hours, 6 minutes, and 28 seconds behind GMT
Assert.assertEquals(diff, expected.getTime() - actual.getTime());
}
> FastDateParserTest.testParses fails in TimeZone America/Sao_Paulo
> -----------------------------------------------------------------
>
> Key: LANG-1104
> URL: https://issues.apache.org/jira/browse/LANG-1104
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
> Affects Versions: 4.0
> Reporter: Charles Honton
> Assignee: Charles Honton
>
> Build works fine with Java 7 and Maven 3.2
> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
> 2014-12-14T15:29:23-02:00)
> Maven home: /opt/apache-maven-3.2.5
> Java version: 1.7.0_76, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-33-generic", arch: "amd64", family: "unix"
> The following test failed though:
> org.apache.commons.lang3.time.FastDateFormat_ParserTest:
> java.lang.AssertionError: ms_MY Sat Feb 10 01:53:32 BRT 1900
> GGGG/yyyy/MMMM/dddd/hhhh/mmmm/ss/aaaa/EEEE/ZZZZ
> America/New_York expected:<Sat Feb 10 01:53:32 BRT 1900> but was:<Sat Feb 10
> 01:53:04
> BRT 1900>
> Build fails with Java 8 and Maven 3.2. Same test fails.
> Failed tests:
>
> FastDateFormat_ParserTest>FastDateParserTest.testParses:250->FastDateParserTest.validateSdfFormatFdpParseEquality:227
>
> Sat Feb 10 01:53:32 BRT 1900 GGGG/yyyy/MMMM/dddd/hhhh/mmmm/ss/aaaa/EEEE/ZZZZ
> America/New_York
> expected:<Sat Feb 10 01:53:32 BRT 1900> but was:<Sat Feb 10 01:53:04 BRT 1900>
> My time zone is set to America/Sao_Paulo, GMT -3,
> and I suspect that that failing test is in someway related to my time zone.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)