On Thu, 2010-02-04 at 13:19 -0600, [email protected] wrote: > > I've got an issue with needing to be able to run cron jobs at times > > relevant to various cron jobs. I'm pretty sure I can't do this with > > standard tools, but am not excited about having to create a whole > solution > > for this. Does anyone have a suggestion for how to address this? > > For the record, this is one of the reasons i think timezones and day > light > > savings should both be abolished. Lets throw in a mandatory 24hr clock > > just for kicks. People would get used to it eventually. :) > I apologize, I should have taken an extra minute to re-read my message. I > am trying to work with timezones and cron together. IE Server is on CST, > needs to run reports at 4pm in EST, CST, MST, and PST. > I have been browsing through search results as well, and have seen some > interesting results, but nothing usable.
First off, the problem with scheduling is that UTC/GMT is _useless_. Scheduling is almost always expected under localtime. You should _never_ store scheduled events on UTC/GMT, because the offset for localtime could change. In some countries, the rules of offset changes is not even fixed for the future, unlike the US (where rules are fixed, although they can change every few decades). So, for any scheduled event, it should be stored _with_ the Zoneinfo path of the timezone it is tied to. Secondly, as you know, the system has a system-wide Zoneinfo path (e.g., America/New_York) that is set as /etc/localtime (either a copy or, if one can guarantee /etc is always on the same filesystem as Zoneinfo, a symlink). However, Linux, per recent IEEE POSIX standard, supports setting per-user Zoneinfo in the TZ variable. E.g., "export TZ=America/New_York". As long as the path is available in the Zoneinfo database (/usr/share/zoneinfo on Fedora/Red Hat-based distros), it should work. This is a newer development in the POSIX standard, so implementation may not be the same on older releases of POSIX systems. As such, your cron jobs should set this variable first, before executing additional commands. To simplify matters, you could consider setting up users with profiles for different Zoneinfo paths, and kick off cron jobs under each. E.g., cron_nyc, cron_chi, cron_den, etc... BTW, the legacy timezone abbreviations are very much deprecated in POSIX standards, because they are ambiguous and incomplete. Zoneinfo should always be utilized, as it contains complete, unambiguous, historical offsets for any region. http://en.wikipedia.org/wiki/Zoneinfo http://en.wikipedia.org/wiki/List_of_zoneinfo_time_zones -- Bryan J Smith Senior Consultant Red Hat, Inc Professional Consulting http://www.redhat.com/consulting mailto:[email protected] +1 (407) 489-7013 (Mobile) mailto:[email protected] (Blackberry/Red Hat-External) -------------------------------------------------------- You already know Red Hat as the entity dedicated to 100% no-IP-strings-attached, community software development. But do you know where CIOs rate Red Hat versus other software and services firms for their own, direct needs, year after year? http://www.redhat.com/promo/vendor/ _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
