[
https://issues.apache.org/jira/browse/TRINIDAD-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733899#action_12733899
]
Yee-Wah Lee commented on TRINIDAD-1512:
---------------------------------------
Sent an email out to dev mailing list, discussing if this is a JDK issue.
Excerpting the relevant code here:
1) DateTimeConverter.java#getFormattingTimeZone(TimeZone tZone)
This effectively creates a timezone with customized id. TimeZone zone =
(TimeZone) tZone.clone();
// set the id as "GMT Sign Hours : Minutes"
StringBuilder zoneId = new StringBuilder(9);
int rawOffset = zone.getRawOffset();
.. code to calculate and append GMT ± hours:mins
zone.setID(zoneId.toString());
return zone;
2) JDK 1.5: SimpleDateFormat#subFormat()
The 1.5 format code would look up a zone info file using the date's offset and
daylight savings.
case 17: // 'z' - ZONE_OFFSET
int zoneIndex =
formatData.getZoneIndex(calendar.getTimeZone().getID());
if (zoneIndex == -1) {
value = calendar.get(Calendar.ZONE_OFFSET) +
calendar.get(Calendar.DST_OFFSET);
buffer.append(ZoneInfoFile.toCustomID(value));
<---------Uses this code path
}....
3) JDK 6: SimpleDateFormat#subFormat()
The 1.6 code now checks the DateFormatSymbols.locale and isZoneStringsSet(). By
default, the locale would be null and zoneStringsSet = false unless user
overrides either.It then calls TimeZone.getDisplayName() instead of checking
the zoneInfoFile.
case 17: // 'z' - ZONE_OFFSET
if (formatData.locale == null || formatData.isZoneStringsSet) {
..
// same as 1.5, looks up zone info file
String[][] zoneStrings = formatData.getZoneStringsWrapper();
buffer.append(zoneStrings[zoneIndex][index]);
} else {
TimeZone tz = calendar.getTimeZone();
boolean daylight = (calendar.get(Calendar.DST_OFFSET) != 0);
int tzstyle = (count < 4 ? TimeZone.SHORT : TimeZone.LONG);
buffer.append(tz.getDisplayName(daylight, tzstyle,
formatData.locale)); <------------ Uses this code path
}...
4) JDK 1.5/6: TimeZone.getDisplayName()
This method is the same in both JDKs, but only called in JDK 6 case. If the ID
is customized (GMT ±x), it simply returns that.
String id = getID();
String[] names = getDisplayNames(id, locale);
if (names == null) {
if (id.startsWith("GMT")) {
char sign = id.charAt(3);
if (sign == '+' || sign == '-') {
return id;
Therefore, the display name for the Converter's timezone in JDK 6 is fixed as
its ID (GMT+/-rawOffset).
> ConvertDateTime uses static GMT+x string for timezone display, doesn't update
> for daylight savings
> --------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1512
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1512
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.11-core
> Reporter: Yee-Wah Lee
> Priority: Minor
>
> 1. Create a jsp that uses tr:convertDateTime to display timezone, e.g.
> <af:outputText value="#{demoInput.date}">
> <af:convertDateTime type="both" timeStyle="full"
> timeZone="America/New_York"/>
> </af:outputText>
> where demoInput.date returns the current date, e.g. June 17 09, 1:00 PM
> 2. Run the jsp. For June 17 09 the timezone is actually EDT (GMT - 4).
> Instead it displays as EST
> 6/17/2009 1:00:00 PM GMT-05:00
> If using the JSF standard DateTimeConverter, the output is:
> Jun 17, 2009 1:00:00 PM EDT
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
