I need help understanding how daylight savings time and daily standard time will affect our jobs.
The docs say that CRON schedules will run at the same time of day regardless of daylight savings time. "CronTrigger allows you to schedule jobs to fire at certain moments with respect to a "gregorian calendar". Hence, if you create a trigger to fire every day at 10:00 am, before and after daylight savings time switches it will continue to do so."
The docs don't mention how DST affects WithDailyTimeIntervalSchedule.
What I don't understand with either CRON or WithDailyTimeIntervalSchedule is: If I schedule a job to run at 10:00 AM UTC, which is 6:00 AM EST half of the year, but is 5:00 AM EST the other half, won't my schedule run at these different EST hours depending on whether we are in Daily Time versus Standard Time?
Or do we need to save them with the TimeZonedID that we want to run them in (like "Eastern Standard Time")?
I realize this isn't a quartz specific question. Just trying to get some help understanding this.
Thanks, Brent
Related
So the EU is thinking about scrapping the DST and leave the decision to local government to decide to stay on winter time or summer time.
What does this means for existing code libraries and applications that deal with scheduling, timezone conversion etc?
Example,
Suppose currently depends on DST, my country time can be +8 UTC (summer) or +7 UTC (winter).
After the EU change, my country time permanently +8 UTC.
If I have a schedule to send me an email everyday at 9:00:00 am (local time), I might save 9am in the database, then check
if(Date.utcNow().format(H:i:s, MY_TIMEZONE) == 09:00:00) sendEmail();
Will this code still work regardless of summer or winter after the EU change?
Alternatively, if I store in UTC 1:00:00 am (+0), then
if(Date.utcNow().format(H:i:s, UTC) == 01:00:00) sendEmail(); // actually this will NOT send at the same local time everyday, because I expect it to send at summer or winter time depending on DST.
Will this code automatically send at the new local time summer permanently after the EU change?
I assume someone will fix the time servers, but on my part do I need to update any code libraries and application logic?
It may not be as dire as you fear.
There exists something called the IANA time zone database. And as it turns out, a lot of languages and libraries already use this database to tell them about things like UTC offsets and time zone rules.
And the IANA time zone database itself is not static. It gets updated surprisingly often. And when it does, those platforms, languages and libraries that depend on it will typically update to the newer version as well. So higher level software just continues to work as time zone changes happen.
In the year 2018, the IANA time zone database was updated 9 times. That's about every 6 weeks on average. So changes in daylight saving rules are neither rare (on a global scale) or catastrophic.
Though the worst thing that can happen (and does with disturbing frequency) is for some brain-dead government to give less than a week's notice of changing daylight saving rules. Then, for that part of the world, there is confusion about the current time until all systems have had enough time to update.
In the EU's case, it appears that things are being thought through and planned out well in advance. So the IANA time zone database and all of the systems that depend on it will be able to update in plenty of time.
If you are aware of code that programs its own daylight saving rule logic, instead of depending on a well-maintained, updatable database of ever-changing time zone rules, then the prudent thing to do would be to migrate your code off of that custom logic asap.
As for the part of your question about how to store times for regularly scheduled events, best practice is to store the time stamp exactly as humans intend it. For example if you expect something to happen at 9am local time, then it should be programed for 9am local time. If you expect something to happen at the same instant globally, it should probably be programmed against UTC.
For more advice on best practices in this area, see this SO answer.
Update
Matt Johnson reminds us of the great article he wrote a few years ago which contains good advice for brain-dead governments. If they ever learn how to read, this is the first thing they should read: https://codeofmatt.com/on-the-timing-of-time-zone-changes/
Can I set the time in the day when I allow the background fetch?
Like all the days, no background fetch allowed but in peak hours, from 6 pm to 8 pm, my application will allow background fetch every UIApplicationBackgroundFetchIntervalMinimum (or whatever).
I can only set background fetch frequently (each hour or whatever) and not for a period of the day (or the week, or the month ...).
If someone has an answer or an idea or the beginning of one, I will be really thankful.
Have a good day!
In a web application I'm developing (Ruby on Rails), the user can specify a local time of any location in the world.
(That location is nothing to do with the user's location or the server's location.)
And if Daylight Savings time is used at that location, the user types that time.
I need to get the local time without Daylight Savings for the location from the specified Daylight Savings time.
e.g. The server is in San Francisco. The user is in New York. In winter, the user enters the local time during summer (with Daylight Savings) of Minneapolis. And I need to get the equivalent local time of Minneapolis without Daylight Savings offset. Suppose that we don't have information if Daylight Savings Time is used in Minneapolis or not.
Because the user can specify any location in the world, we cannot tell if that location uses Daylight Savings Time. Also the UTC offset information itself doesn't tell if it's in Daylight Savings Time or not.
How can I do this?
Any help will be greatly appreciated?
The olson TZ database (available via the tzinfo gem) does contain information about whether each location uses daylight savings or not (and when that period starts/finishes). You should usually use the timezone objects it provides rather than raw utc offsets. When you've got a timezone object the local_to_utc method will do the conversion for you, applying DST as appropriate.
The only ambiguous case is when the clocks go back: there is one hour a year during which the local time can correspond to two distinct points in time. In the uk for example at the end of October the clocks go back one hour at 1:59:59 - if a user tells you the local time 1:30:00 you won't know if it is the first or second 1:30. Tzinfo can tell you both of the possibilities so that you can pick based in your own logic.
We have a Quartz.NET cron trigger setup that needs to execute a job using the following schedule:
At 02:00hrs in the merchants time zone daily
However, when Daylight Savings Time (DST) occurs abnormalities occur i.e:
When the merchants timezone moves from +2 GMT to +3 GMT, the job does not get executed.
When the merchants timezone moves from +3 GMT to +2 GMT, the job does gets executed twice.
We already know that this behaviour is by design (http://www.quartz-scheduler.net/faq.html#daylight) but what are people using as a solution to this DST issue?
Cheers
Billy Stack
The link you point to may have been updated in the three years or so (!) since you asked this question. It would appear that the job should not be executed twice.
I'm unsure whether 02:00 officially 'occurs' in the US when daylight savings starts, so the concern about the job skipping execution at 02:00 could be resolved by setting it to 01:59:59 (cron trigger "59 59 1 ? *"), as long as you were in North America. Other countries may change at a different time of night. In Europe, for instance, the change is at 01:00, so there it would be better to set the trigger to 02:00:01
Just experienced the same issue as well, although in my case the trigger was not scheduled to fire between 0:00 and the DST change time (2:00 in the US). Instead, I had a job that runs MON-FRI at 8 in the morning, so it ran twice on the Monday November the 5th, the day following the DST change day.
If you read the FAQ item linked to in the question, it kinda makes sense. The Cron trigger wakes up, fires the job, then calculates next time to wake up. When it woke up on Friday at 8am, it calculated next time to run as Monday at 8am. However, by Monday morning what used to be 8am became 7am, so the trigger fired at that time. And then when it ran, the next time was "correctly" calculated as 8am, so it ran again at that time also.
Hope this helps somebody struggling to understand the issue.
Jobs run twice in the fall and don't run at all in the spring. It doesn't matter what time they are scheduled. The question was and still is, "How do you stop this from happening?" If you manually delete all jobs after the time change and before they run then add them back then it works fine. I haven't looked at it yet but thinking this could be automated. Write something that reads all scheduled jobs and adds them and deletes the old records. Whatever you write would need to run from the Windows job scheduler because it wouldn't run at all in the spring if it ran from Quartz.
My calendar works properly on servers in PST but on the production server (EST) all events seem to end one day early. I am not sure if it is a timezone problem because even with the 3 hour difference the events should be display on the proper date.
Has anyone else encountered this issue?
This is typical problem when crossing timezone barriers. If only the date is carried by the database, but the data is converted to timestamp and adjusted for timezone you have the problem 2010-06-02 becomes 2010-06-02 00:00 EST becomes 2010-06-01 21:00 PST.
If the events end a day early but don't start a day early, it's likely your back-end scripts aren't getting or aren't respecting the end-date timezone information coming from the browser. If events start at midnight PDT (or 3am EDT) and but end at midnight EDT (or 9pm PDT) or maybe midnight GMT (or 4pm PDT), that would account for events "ending early". The browser should be sending all events with full datetime information (e.g. '6/3/2010 00:00:00 GMT-0800') and the back-end scripts be saving and reporting this information faithfully as well.
I live in Japan but do a lot of development in North America, so I see this problem constantly. I find it really helps development to think about all events in GMT rather than your own home timezone -- especially if any of your users live in different timezones. JS handles timezone information pretty well (aside from the lack of awareness of Daylight Saving Time, it works fantastically), and most servers do timezone extremely well, so most bugs you see have to do with client scripts sending incomplete date information and trying to make do.
It's also worth checking to see how your application works on November 7 2010 at 2:00am, since that day is 25 hours long and March 13, 2011, since that day's only 23 hours long. The switch to DST is a devil.