You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've identified an issue with the getNameKey function in version 2.13.0 of Joda-Time. For certain valid IANA timezone identifiers, the getNameKey method returns "%z" instead of the expected name key. This issue does not occur in version 2.12.7, where the function works as expected.
The following timezones are known to exhibit this issue:
Asia/Dubai (Gulf Standard Time)
Asia/Ho_Chi_Minh (Vietnam UTC+7)
Asia/Singapore (Singapore UTC+8)
Other timezones, such as America/Los_Angeles (Pacific Standard Time) and America/New_York (Eastern Standard Time), return the correct results. It is possible that additional timezones are affected, but these are the ones I have identified so far.
Test case
import org.joda.time.DateTimeZone;
public class TimezoneTest {
public static void main(String[] args) {
// Testing specific timezones for the getNameKey function
String[] timezones = {
"Asia/Dubai", // Gulf Standard Time
"Asia/Ho_Chi_Minh", // Vietnam (UTC+7)
"Asia/Singapore", // Singapore (UTC+8)
"America/Los_Angeles", // Pacific Standard Time
"America/New_York" // Eastern Standard Time
};
long currentTimeMillis = System.currentTimeMillis();
System.out.println("Testing Joda-Time getNameKey function:");
for (String timezone : timezones) {
try {
DateTimeZone zone = DateTimeZone.forID(timezone);
String nameKey = zone.getNameKey(currentTimeMillis);
System.out.printf("Timezone: %s -> Name Key: %s%n", timezone, nameKey);
} catch (IllegalArgumentException e) {
System.err.printf("Timezone: %s -> Error: %s%n", timezone, e.getMessage());
}
}
}
}
Results
When running the above code with Joda-Time version 2.13.0, the output is:
Testing Joda-Time getNameKey function:
Timezone: Asia/Dubai -> Name Key: %z
Timezone: Asia/Ho_Chi_Minh -> Name Key: %z
Timezone: Asia/Singapore -> Name Key: %z
Timezone: America/Los_Angeles -> Name Key: PST
Timezone: America/New_York -> Name Key: EST
As shown, the timezones Asia/Dubai, Asia/Ho_Chi_Minh, and Asia/Singapore return "%z" instead of the expected name key. This behavior is inconsistent with the output in version 2.12.7, where the correct name keys are returned.
Additional Notes
This issue might be more widespread and affect other timezones. However, the provided test case highlights the timezones I have verified as problematic. I would appreciate it if this issue could be reviewed and addressed in a future release. Thanks!
The text was updated successfully, but these errors were encountered:
Key information
Joda-Time version: 2.13.0
Problem description
I've identified an issue with the getNameKey function in version 2.13.0 of Joda-Time. For certain valid IANA timezone identifiers, the getNameKey method returns "%z" instead of the expected name key. This issue does not occur in version 2.12.7, where the function works as expected.
The following timezones are known to exhibit this issue:
Asia/Dubai (Gulf Standard Time)
Asia/Ho_Chi_Minh (Vietnam UTC+7)
Asia/Singapore (Singapore UTC+8)
Other timezones, such as America/Los_Angeles (Pacific Standard Time) and America/New_York (Eastern Standard Time), return the correct results. It is possible that additional timezones are affected, but these are the ones I have identified so far.
Test case
Results
When running the above code with Joda-Time version 2.13.0, the output is:
As shown, the timezones Asia/Dubai, Asia/Ho_Chi_Minh, and Asia/Singapore return "%z" instead of the expected name key. This behavior is inconsistent with the output in version 2.12.7, where the correct name keys are returned.
Additional Notes
This issue might be more widespread and affect other timezones. However, the provided test case highlights the timezones I have verified as problematic. I would appreciate it if this issue could be reviewed and addressed in a future release. Thanks!
The text was updated successfully, but these errors were encountered: