[QTZ-463] Incorrect Cron Trigger start time on DST end date when using
different time zone Created: 09/Sep/14 Updated: 09/Sep/14
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
New
Quartz Scheduler
Triggers
2.2.1
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Bug
Christopher White
Unresolved
None
Not Specified
Terracotta
Target:
Unknown
None
Priority:
Assignee:
Votes:
2 Major
Issue Review Board
0
Not Specified
Not Specified
Description
An incorrect start time is set on a Cron Trigger when the provided start time is on the date when
DST ends (for the time zone where Quartz is running) and the hour is equal to 1 hour before the
DST end hour, and the time zone set on the trigger is different than the time zone where Quartz
is running.
If such a scenario is encountered, the trigger start time is ultimately set to 1 hour later than the
desired start time.
An example will make this much clearer:
Let's say I want to create a cron trigger with a start date of 10pm on November 1, 2014, with a
time zone of "America/Los_Angeles". And Quartz is running on a server in time zone
"America/New_York". 10pm in Los Angeles is equivalent to November 2 at 1am EDT (the first
Sunday in November when DST will end at 2am for New York). This will ultimately create a
cron trigger that has a start time of 11pm on November 1, 2014 in time zone
"America/Los_Angeles" (instead of the desired 10pm that was originally specified).
This issue occurs because a time zone is NOT specified while creating a Calendar instance
when setting the start time on the cron trigger. Specifically: within class CronTriggerImpl.java,
method setStartTime, line 393.
Because the time zone is not used, it is assumed that the time is in New York time zone (which
would then be 1am EDT). After executing the line of code to clear the milliseconds, the
Calendar instance no longer returns 1am EDT, but instead returns 1am EST. And now, when
the date is translated back into Los Angeles time, the value is incorrect.
Generated at Tue Feb 09 11:33:07 PST 2016 using JIRA 6.2.4#6261sha1:4d2e6f6f26064845673c8e7ffe9b6b84b45a6e79.