Igor Rodchenkov created LANG-1791:
-------------------------------------
Summary: FastDateFormat behavior changed between 3.0.1 and e.g.
3.18.0 and later
Key: LANG-1791
URL: https://issues.apache.org/jira/browse/LANG-1791
Project: Commons Lang
Issue Type: Bug
Environment: Linux (Ubuntu 24.04), temurin-17.0.16 JDK, run in Toronto.
Reporter: Igor Rodchenkov
Lately, we discovered a bug which is better demonstrate with this test case
(it's not perfect because always passes in GMT zone, but e.g. in Toronto it
passes when commons-lang3 v3.0.1 used and fails when v3.18.0 or 3.19.0 is used;
and yes, in this special case, we have somewhat legacy java code using Calendar
etc., but that was what broke in our app by this library upgrade, which
supoosed to be backward compatible):
{code:java}
/*
* org.apache.commons.lang3.time.FastDateFormat
* In dateFormatter.format(timeCal), when time was not set explicitly, would
make e.g.
* the following timestamps in Toronto at 10 am on 2025-09-17:
* "2025091714" - UTC, as expected, when using commons-lang3 v3.0.1
* "2025091710" - EDT, when using commons-lang3 v3.18.0 :(
*/
@Test
public void fastDateFormatFormatterUsingCalendarShouldMakeGmtTimestamp() {
FastDateFormat dateFormatter = FastDateFormat.getInstance("yyyyMMddHH");
TimeZone timeZone = TimeZone.getTimeZone("GMT");
Calendar timeCal = Calendar.getInstance(timeZone);
Date time1 = timeCal.getTime(); //in local time zone
ZoneId zone = ZoneId.systemDefault();
ZoneOffset off = zone.getRules().getOffset(time1.toInstant());
System.out.printf("Time: %s, zone: %s, offset(s): %s\n", time1, zone,
off.getTotalSeconds());
String timestamp1 = dateFormatter.format(timeCal); //makes local zone
timestamp when commons-lang3 v3.18.0 is used.
Date time = Date.from(Instant.now().minusSeconds(off.getTotalSeconds()));
String timestamp2 = dateFormatter.format(time); //GMT timestamp
assertEquals(timestamp2, timestamp1);
}{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
