You don't state if it is a workstation or a server. For workstations, local time zone is sufficient. Servers, especially production servers, should be set to UTC or GMT (pick your flavor) and the CLIENT applications should make the time conversions as necessary.

Yes, this is quite a common occurance.

hope this helps

Jason

I was speaking about a server that hosts my perl application, and crontab entries.

I setup a sandbox solaris 8 machine and I ran a number of tests by manually changing the time. I have discovered the following:

* If the `date` command is used by root to change the time, the next crontab entry is not executed properly (or at all it seems) even if the clock runs through the proper time.

* Solaris 8 changes to the DST (PDT) using a time zone conversion at 2am (at least by my american, PST localization settings). This causes cronjobs scheduled to run between 2am and 3am in spring time conversion window to not execute.

* None of this is documented in man cron or man crontab.

* Google has a few discussions on this for various flavors of unix. Lots of speculation, not a lot of facts though.

Thanks for the input!

-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday

Hi Michael,


I'm dealing with various levels of production as well as the classical test, QA and development servers all day long so the first thing I was ask is Production?. Sorry if it came out the wrong way..

Jason L. Froebe

No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Two, it's called "daylight saving time" (not savings). You make it sound like a bank where you can withdraw a little extra on a rainy day.

Three, DST in the USA jumps from 2am to 3am (occasionally called the Devil's Hour), or from 2am to 1am (occasionally called the Witch's Hour (not to be confused with the Witching Hour of midnight)).

Four, yes, some versions of the documentation for cron has included such operational notes nearly since its invention. Cron won't fire events for a time which never happened. Cron will fire events twice for times which happen twice.

This is another reason you should update your system time carefully and gradually with ntpd instead of with lurching adjustments like crontab: 11 1 * * * fixtime. If you somehow skip a whole minute, that system backup might not happen.

There are some cron-aids available which can help you. I think one is called anacron. This helps those folks who shut down their computer many nights, or fold their laptops at unpredictable times, but still want a "nightly" backup or a regular database update.

And regardless of whether it's called "daylight saving time" or "daylight savings time", it is nothing of the sort, for it does not change the amount of daylight. If it were to magically store up daylight during the summer and release it over the winter so that I didn't have to get up when it was dark and get home in the dark, then the name might be more truthful, and the concept more useful.

It's a stupid idea anyway, and there is no proof of the supposed benefits.

</rant>

<anti-rant>

Two, it's called "daylight saving time" (not savings). You make it sound like a bank where you can withdraw a little extra on a rainy day.

Google shows 317K hits for "daylight savings time" compared to 321K hits for "daylight saving time". Given the fuzziness of Google, and the human propensity to drop the last letter of a word, you could argue either way.

I personally have only heard "savings", and that's what I use.

I suppose your personal usage depends on whether you prefer the verb "saving" over the noun "savings". Or if you agree with the usage problem noted in some dictionaries, then similar phrases like Woodchip Savings Area should be Woodchip Saving Area. Unless you're just stockpiling Woodchips there, and they don't actually get saved there, so it might be more accurate to describe it as a Savings Area.

</anti-rant>

-QM
--
Quantum Mechanics: The dreams stuff is made of

Hm, I googled for "daylight savings time" (with quotes) and I see ~299K hits. On the first page of hits, all but one of the titles were in the singular, and three of the blurbs include a corrective note: e.g., not Daylight Savings Time.

Also, since the USA thing is an official act of Congress, one could look up the official name of it. Saving. Each time they touched the act, on at least four different occasions, they named it in the singular.

Though I agree that English is a "living" language, Google ain't the definitive reference of proper spelling. If so, we should all say PERL, not Perl.

--
[ e d @ h a l l e y . c c ]

If you're in Europe, the switch occurrs at 1:00am Universal Time. So if you're in europe, it's possible that your cron job bumped into the DST switch.

The other thing to remember is that the clock doesn't actually change for DST. Your timezone changes. You go from, for example, Pacific Standard Time to Pacific Daylight Time. Unfortuantely, if I recall, cron isn't timezone aware, so there's a good chance that it does get confused when the computer's timezone changes and suddenly cron finds itself operating in an environment that thinks it's 3:00am local time versus 2:00am local time. In that case, jobs can get skipped, at least according to what bit of googling and reading I've done.

I think that shouldn't cause problems, even if cron was told to run the script between 2am and 3am. If you shut down your machine between 2am and 3am on a normal day (not on a day when dst setting occurs), cron will run the job scheduled to 2:30 when you next start it, that is, at 3am. I don't know how exactly cron works, so DST setting may be different.

(By the way, I think that here dst setting is from 2am to 3am in the spring, and from 3am to 2am in the automn.)