Issue with getNameKey returning %z for certain timezones in Joda-Time 2.13.0 #800
Description
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
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!