So after some investigations I think we are observing different issues.
The issue from Paulo is one of the most nasty ones: the UI date picker
is not playing well with the isLatin() annoyance in the code (grr.. all
time could have been handled in 24h format internally).
We are aware of this bug and we will send a patch.
About the other issues:
1) On a 1.7 server
1.1) I set my profile to use GMT+1 (Europe Central)
1.1.1- The (old) date picker shows CEST
1.1.2- The event pending page shows CEST (this is a perl page)
1.1.3- The event history page shows CEST (this is a perl page)
1.2) I set my profile to use GMT -5 United States (Eastern)
1.2.1- The (old) date picker shows EDT
1.2.2- The event pending page shows EDT (this is a perl page)
1.2.3- The event history page shows EDT too (this is a perl page)
2) On a 2.1 server
2.1) If I have profile set to Central European Time
2.1.1- Date picker shows CET
2.1.2- Pending events shows CEST (!!) (this is a perl page)
2.1.3- History page shows time in CEST (this is a Java page)
2.2) If I set the profile to United Stated (Eastern) (GMT-5)
2.2.1- Date picker shows EST
2.2.2- Pending events shows EDT (!!) (this is a perl page)
2.2.3- History page shows time in CEST (this is a Java page)
What can we learn from this:
The differences Ron sees in the date picker 1.2.1 vs 2.2.1 is probably
because the original date picker did:
<fmt:formatDate value="${picker.date}" pattern="z"
timeZone="${picker.calendar.timeZone}"/>
and the new one does
picker.getCalendar().getTimeZone().getDisplayName(false, TimeZone.SHORT,
data.getLocale()));
Where the "false" there is "daylight":
daylight - true specifying a Daylight Saving Time name, or false
specifying a Standard Time name
Therefore, even if we are using the same timezone, we are forcing the
wrong name(so the issue is cosmetic).
I changed this to:
DateFormat tzFmt = new SimpleDateFormat("z", data.getLocale());
tzFmt.setTimeZone(data.getCalendar().getTimeZone());
and use tzFmt.format(data.getDate()) and I get EDT as expected.
So I will send a patch on this too.
(note that other parts of spacewalk use
LocalizationService.getInstance().formatDate(), including the new
rhn:formatDate, which still shows EST)
2.2.3 is probably to the porting of the perl page to Java. The date is
sent to the screen "as is" and therefore it uses the timezone of the
server and not the one the user has configured. This can be fixed by
using the rhn:formatDate we introduced that uses the profile timezone. I
am preparing a patch for this as it requires a small bug fix first.
However this last item probably does not affect much people. I guess
most are using the same timezone on the server and their profile.
Regards,
Duncan
_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list
