Rufus-scheduler introduced ZoTime in 3.1.0, and since then ENV['TZ'] may get modified in run time, where other threads may be creating Time objects or spawning child processes.
So, my question is, when do ZoTime#time and ZoTime#utc have a chance to be called? Is it only when a schedule is registered using a time zone in the cron line, or is there a chance to be re-evaluated when some event occurs?
as you guessed ZoTime#time is called upon registering a cron schedule.
It is also called upon a CronJob#next_time or a CronJob#previous_time.
ENV['TZ'] is consulted by cron jobs when there is no definite time zone in the cron string (upon creation and for #next_time and #previous_time. That might be a problem (maybe that's what prompted you to open this issue). One solution could be to keep track of the timezone at the point of creation of the CronJob instance.
I'd be glad to help once I know exactly what bothers you.
Thanks for the quick reply!
I have a system that persistently runs a scheduler built with rufus-scheduler, and the system dynamically adds or deletes schedules upon a request via API. Each schedule periodically invokes a specified job on a specified time/interval, and the process involves running an external command, making an HTTP request and accessing DB while executing jobs.
So, what I need here is make sure jobs are not affected by registration of new schedules.
Ah, I understand. Indeed, the calls to ZoTime#in_zone are problematic. I will study how to avoid using it. It's currently used in two places in ZoTime.
Thanks for reporting that. Please give me a few days.
Great. Thanks for taking the time! Actually I was about to start working on a PR, but before that I just wanted to know what you'd think about the idea of fixing it.
OK, got it. I'd be glad to have a PR from you.
After some investigation, I've found you need to add back the parser for TZ values. TZInfo or ActiveSupport::TimeZone can parse timezone representations like Asia/Tokyo or PST, but not JST-9. It is likely you could do that better. 😥
I will bring back the dependency on TZInfo and cook something based on it that doesn't touch ENV['TZ'].
Explore TZInfo backed ZoTime for gh-220
Work in progress
Store UTC seconds in ZoTime, gh-220
Drop ZoTime#time, gh-220
Reorganize ZoTime spec, gh-220
Introduce %/Z for ZoTime#strftime, gh-220
Default ZoTime to ENV['TZ'], gh-220
Delegate from ZoTime to its #to_time, gh-220
Move from .parse_to_time to ZoTime.make, gh-220
Tighten ZoTime.parse, gh-220
Implement ZoTime#<=>, gh-220
Move #monthdays from CronLine to ZoTime, gh-220
Rework CronLine#next_time, gh-220
Rework CronLine#previous_time, gh-220
Reorganize #[brute_]frequency specs, gh-220
It's taking its time but it's starting to look good.
Cache ZoTime#to_time result into @time, gh-220
Store timezone instance in CronLine, gh-220
Still, the "shortest delta" specs are 3 times slower than they were before this gh-220 rework. Digging...
Move #to_compact_s to ZoTime#to_utc_comparison_s
Adapt CronLine spec to explict @timezone, gh-220
Beforehand, the local timezone in the CronLine was stored as `nil`, from gh-220 on, it is stored as a TZInfo::Timezone (like CronLine with non-local timezones).
Complete adaptation of cronline_spec.rb to gh-220
Though it's running in ~19.5 seconds vs ~7.0 seconds (pre gh-220) on Ruby 2.2.5p319.
Make it run, make it fast.
Use ZoTime within jobs, gh-220
Adapt at spec to gh-220
Rework @first_at computation for gh-220
Move away from Forwardable, gh-220
Use ZoTime everywhere in the scheduler, gh-220
Bring back Date.parse check for Ruby 1.8, gh-220
Adapt ZoTime.parse to Ruby 1.8, gh-220
Add ZoTime#utc_offset, gh-220
Adapt various specs to [my] Ruby 1.8, gh-220
Introduce ZoTime / Time #to_debug_s, gh-220
Focus on utc_offset instead of zone name (which various wildly between 1.8, 2.x or JRuby)
Fix ZoTime.parse for Ruby 1.9 and JRuby 1.9 mode
Fix ZoTime.parse for Ruby 2.1 as well, gh-220
Hello, apart from a slight problem with JRuby, this transition is done.
If you have the time, please have a look 781c009...184bd6a
Your comments are welcome.
Many thanks for making me realize the problem behind my ENV['TZ'] approach.
I will close this issue soon. I'll release this as part of the upcoming 3.3.0
Wow, this must have been a tough work! Thanks!
I've deployed the current master to my personal installation and so far it's been working fine.
Thanks, closing for now !