[Spacewalk-list] Incorrect timezone in new 2.1 date / time picker.

[Coffman, Anthony J]

Just my two cents.

I ran a large scheduled action on March 9th 6:00am and March 16 6:00am.

Both were run using Spacewalk 2.1 on the server and Spacewalk proxies.  The Spacewalk clients were running 2.0 code.

I'm in the EST/EDT timezone.

The action for March 9th was actually scheduled on March 8 just a few hours before the time switch. So the action was scheduled before the switch but it executed after the switch.

The action for March 16 was scheduled on March 14.

Both actions ran exactly on schedule (I was observing and waiting for them to finish.

--Tony


-----Original Message-----
From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Cliff Perry
Sent: Monday, March 31, 2014 4:43 AM
To: spacewalk-list at redhat.com
Cc: Ron Helzer; spacewalk-devel
Subject: Re: [Spacewalk-list] Incorrect timezone in new 2.1 date / time picker.

On 28/03/14 16:16, Duncan Mac-Vicar P. wrote:
> On 28/03/14 17:05, Ron Helzer wrote:
>> There's only one other GMT-0500 timezone choice available (Indiana), 
>> where they don't observe DST... That, in conjunction with the fact 
>> that there were no DST issues pre-2.1, would suggest to me that the 
>> GMT-0500 (Eastern) setting should account for EDT/EST change.
>>
>> Are you suggesting I'm supposed to change the preference twice a year 
>> to manually account for DST?
>
> No, I am just trying to understand where the issue can come from, as I 
> don't think anything changed at all.
>
> In 2.0 the date picker fragment got the timezone from the DatePicker 
> bean (picker.calendar.timeZone) 
> https://github.com/spacewalkproject/spacewalk/blob/SPACEWALK-2.0/java/
> code/webapp/WEB-INF/pages/common/fragments/date-picker.jsp
> (line 60)
>
> In 2.1, the JSP tag gets the timezone from the DatePicker bean in the 
> same way 
> https://github.com/spacewalkproject/spacewalk/blob/SPACEWALK-2.1/java/
> code/src/com/redhat/rhn/frontend/taglibs/DateTimePickerTag.java
> (line 225)
>
> Then the time passed to the server on submit does not carry the 
> timezone, so it is always relative to the one it was shown to you.
> (I am not saying there is not a problem, but I can't see how it would 
> be new if there is).
>
> CCing -devel in case anyone sees something I am missing.

I'm not 100% certain this is correct - pretty sure I am though

  - So, date/timezone is a bit weird some times.
  - User sets timezone, such as EST, we will then display everything in UI based on that timezone for events that happened. If the user schedules something, we will then store in the DB with the off-set used.
  - Assuming the OS timezone and date are correct, then the DB entries for future stored events are correct - based on when the user in UI expected it to happen.
  - System checks in, and picks up event, based on Spacewalk date for scheduled event, NOT the managed systems date/time.

So, not commenting/helping with respect to code, just giving extra color.

Cliff

>
> --
> Duncan Mac-Vicar P. -http://www.suse.com/
>
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix 
> Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, 
> Germany
>
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list