-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
7u51
-
x86_64
-
linux
FULL PRODUCT VERSION :
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux i5 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
EXTRA RELEVANT SYSTEM CONFIGURATION :
LC_ALL=C LANG=C TZ=UTC
A DESCRIPTION OF THE PROBLEM :
Test succeeds with jdk7u17 and u21, but fails at the assertEquals line from u25 onwards because 'millis' evaluates as 1000.
@Test
public void testSimpleDateFormatDefaultTimeZone() throws ParseException {
TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"));
SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
long millis = sf.parse("1927-12-31 23:54:08").getTime()
- sf.parse("1927-12-31 23:54:07").getTime();
assertEquals(millis, 353000L);
}
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
353000
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
package de.mstier.evaluation.tests;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.TimeZone;
import org.junit.After;
import org.junit.Test;
import static org.junit.Assert.*;
public class TimeZoneTest {
private final static TimeZone defaultTimeZoneBackup = TimeZone.getDefault();
@After
public void afterTest() {
// restore default timezone to avoid introducing interdependencies between the test units...
// (avoid using compile-on-save in Netbeans... it will save the class using lmod time from
// the wrong timezone and therefore refuse to update it upon further changes!)
TimeZone.setDefault(defaultTimeZoneBackup);
}
/**
* SimpleDateFormat seems to use the default timezone that was active during its constructor
* execution...
*
* @url http://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result
* @url http://stackoverflow.com/questions/21784002/did-jdk7u25-introduce-a-timezone-bug
* @throws ParseException
*/
@Test
public void testSimpleDateFormatDefaultTimeZone() throws ParseException {
TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"));
SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
long millis = sf.parse("1927-12-31 23:54:08").getTime()
- sf.parse("1927-12-31 23:54:07").getTime();
assertEquals(millis, 353000L);
sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
millis = sf.parse("1927-12-31 23:54:08").getTime()
- sf.parse("1927-12-31 23:54:07").getTime();
assertEquals(millis, 353000L);
sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
millis = sf.parse("1927-12-31 23:54:08").getTime()
- sf.parse("1927-12-31 23:54:07").getTime();
assertEquals(millis, 1000L);
}
}
---------- END SOURCE ----------
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux i5 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
EXTRA RELEVANT SYSTEM CONFIGURATION :
LC_ALL=C LANG=C TZ=UTC
A DESCRIPTION OF THE PROBLEM :
Test succeeds with jdk7u17 and u21, but fails at the assertEquals line from u25 onwards because 'millis' evaluates as 1000.
@Test
public void testSimpleDateFormatDefaultTimeZone() throws ParseException {
TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"));
SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
long millis = sf.parse("1927-12-31 23:54:08").getTime()
- sf.parse("1927-12-31 23:54:07").getTime();
assertEquals(millis, 353000L);
}
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
353000
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
package de.mstier.evaluation.tests;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.TimeZone;
import org.junit.After;
import org.junit.Test;
import static org.junit.Assert.*;
public class TimeZoneTest {
private final static TimeZone defaultTimeZoneBackup = TimeZone.getDefault();
@After
public void afterTest() {
// restore default timezone to avoid introducing interdependencies between the test units...
// (avoid using compile-on-save in Netbeans... it will save the class using lmod time from
// the wrong timezone and therefore refuse to update it upon further changes!)
TimeZone.setDefault(defaultTimeZoneBackup);
}
/**
* SimpleDateFormat seems to use the default timezone that was active during its constructor
* execution...
*
* @url http://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result
* @url http://stackoverflow.com/questions/21784002/did-jdk7u25-introduce-a-timezone-bug
* @throws ParseException
*/
@Test
public void testSimpleDateFormatDefaultTimeZone() throws ParseException {
TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"));
SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
long millis = sf.parse("1927-12-31 23:54:08").getTime()
- sf.parse("1927-12-31 23:54:07").getTime();
assertEquals(millis, 353000L);
sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
millis = sf.parse("1927-12-31 23:54:08").getTime()
- sf.parse("1927-12-31 23:54:07").getTime();
assertEquals(millis, 353000L);
sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
millis = sf.parse("1927-12-31 23:54:08").getTime()
- sf.parse("1927-12-31 23:54:07").getTime();
assertEquals(millis, 1000L);
}
}
---------- END SOURCE ----------