When will at jobs run this weekend?

[Ian Lochray]

I am using the timezone GMT0BST. This weekend, the clocks go back one hour at 2:00 back to 1:00 a.m. I would like to submit two at jobs, one that runs at 1:55 and sets my application into enquiry mode and one that runs at 2:05 a.m. and sets it back to update mode. If I do this, will there really be a 70 minute delay betwwen the two jobs?

[Thierry Poels_1]

Hi,

see "man cron" for DST topic. It is explained, even with examples.

regards,
Thierry.

[Christopher McCray_1]

Yes. I would change the time of the first job to after 0200, or have them both run prior to 0200. Hope this helps

[Thierry Poels_1]

hi again,
the lazy way :
launch them as one job, and put a sleep command between the two steps ;-)

good luck,
Thierry.

[harry d brown jr]

NO there won't be 70 minutes, but for how long, good question. The way the system works, when setting the clock backwards, is that it slows down the clock. So, in simple terms, sometime after 1am, the system will slow the clock down will take more than two minutes, that way a couple of hours later it will be 2am. If the system were to brute force the change, a lot of timestamps would be incorrect, and especially database logging would be toast.

[Volker Borowski]

I think yes !

If you want it to be only down for 10 minutes,
consider to schedule a cronjob at 01:55 that starts at 01:05 only on this specific sunday.

05 01 28 10 * my_job

But keep in mind, that if you run a database application, you might get timestamp confusion.
I.e. an internet-order made at 1:40 may be canceled at 01:20 (later). So perhaps it is better to keep it down for 70 minutes.

Volker

[Ian Lochray]

I have been told that, when this was tried last year, there was only a 10 minute gap between the two at jobs. This is not what the documentation would indicate would happen. It implies a 70 minute gap.
Can someone tell me ...
Is this because the execution time in converted to UCT when the at job is subitted?
Is the time change at 1:59 this weekend as is implied by tztab?

[Darrell Allen]

Hi Ian,

I thought of several things but they would fail according to the cron manpage which says that cron jobs scheduled during an ambigious time (happens during the October time change) are only executed the first time. In your case that would mean 01:00 - 02:00 BST and they would not run during 01:00 - 02:00 GMT.

I think Volker has the solution. Set up your cron to run a job to set inquiry mode at 1:55. At 1:58 have a cron job that reloads your crontab from a saved and edited copy. The edited file should contain everything your current crontab has plus an entry to set update mode at 1:05. Be sure it doesn't contain the job that set inquiry mode.

You crontabs could look like:
Pre time change crontab:
55 1 28 10 0 script to set inquiry
58 1 28 10 0 crontab new_crontab_file
normal cron entries follow

Post time change crontab (new_crontab_file):
5 1 28 10 0 script to set update mode
normal cron entries follow

Result should be:
1:55 BST set inquiry mode
1:58 BST replace crontab
1:05 GMT set update mode

If it makes you feel better, your scripts to set update and inquiry modes could check `date +%Z` for the time zone and only set inquiry if it returns BST and only set update if it returns GMT. I don't believe you'll need that though.

This was a good puzzle. Good luck!

Darrell

[Christopher McCray_1]

Check out these links. They don't answer all your questions, but I think they will shed some light on DSL. Good luck.

http://us-support2.external.hp.com/cki/bin/doc.pl/sid=19c040c8175197a030/screen=ckiDisplayDocument?docId=200000025411328

http://us-support2.external.hp.com/cki/bin/doc.pl/sid=19c040c8175197a030/screen=ckiDisplayDocument?docId=200000026056381

[James R. Ferguson]

Hi Ian:

Wait a minute (no pun!). The system's internal clock DOES NOT CHANGE. Time is maintained in UTC (GMT, if you prefer).

What a user sees, or wishes to see, is determined by the TZ environmental variable. The man pages for 'cron' (1M) and those for 'tztab' (man 4 tztab) will give you a good understanding of how time is externally represented and apparently changed during daylight savings time transitions.

The man pages for 'cron' will also describe the behavior of the time transition, in particular:

"...an ambiguous time refers to an hour and minute that occurs twice in the same day because of a daylight savings time transition (usually on a day during the Autumn season)...
When a command is specified to run at an ambiguous time, the command is executed only once at the first occurrence of the ambiguous time."

Databases, and other applications that wish to keep timestamps would call gmtime() [see 'man 3C ctime'], thereby avoiding the apparent time issue alltogether.

Hopefully this clarifies your questions.

Regards!

..JRF...