Bug 212506 - at -t option gets daylight-saving very wrong
at -t option gets daylight-saving very wrong
Product: Fedora
Classification: Fedora
Component: at (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-10-27 00:02 EDT by JW
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: at-3.1.8-84.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-12-11 09:39:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description JW 2006-10-27 00:02:02 EDT
Description of problem:
The t_option patch applies wrong daylight-saving value to time

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.adjust computer so daylight saving starts at, say, 2006/11/01
2.echo "wrong dst" | at -t 200611021200
3.at -l
Actual results:
1.at will echo "2006-11-02 13:00" or similar

Expected results:
at should echo, and schedule at, the time actually entered, eg "2006-11-02 12:00"

Additional info:
The problem is that in at.c the function t_option() uses the daylight-saving
value for the current time instead of the scheduled time.  The patch is defective.
The correct way to handle this is either:
    tm.tm_isdst = 0;
    t = mktime(&tm);
    if (localtime(t)->tm_isdst != tm.tm_isdst)
        tm.tm_isdst = !tm.tm_isdst;
        t = mktime(&tm);
    tm.ts_isdst = -1;
    t = mktime(&tm);

The latter method is used in parsetime() which seems to work ok.
But the first method is possibly more portable.
Comment 1 Marcela Mašláňová 2006-10-31 04:38:28 EST
Could you tell me what do you use for daylight saving? I can't reproduce it.
You can also try at-3.1.10 from devel. It has some new features.
Comment 2 JW 2006-10-31 04:57:51 EST
Are you sure you have applied patch "at-3.1.8-t_option.patch"?

Are you sure you have followed my exact instructions?

The bug is definitely there still.  Although it is a fairly bad patch because
the touch-format date should really just be added to "parsetime.l" as [0-9]{10}
and [0-9]{12} etc, with appropriate code in "parsetime.y", not with an extra
command-line arg (-t).

I suggest you start by reading the code because the actual bug is very easy to
read and identify.  But if you are having trouble testing for the bug might I
suggest that you use zic to compile an appropriate zone file, install it as
/etc/localtime, RESTART atd (of course), and schedule an event with "at" for a
time after the fictitious zone switches daylight saving.

Very simple really.

But do read the code first!  You can save lots of time that way.  I have already
pointed out exactly what the problem is. It is a next-to-no-brainer.
Comment 3 JW 2006-10-31 05:00:09 EST
Just to clarify:  suppose your zone's daylight saving starts at 2:00 on 1st Nov,
then at 20:00 on 31st Oct you need to schedule an event with "at" for, say, 1st
Nov 10:00. Ok?  You must be in non-daylight time era and be scheduling an event
which is in daylight time era.

Comment 4 Marcela Mašláňová 2006-11-06 09:10:24 EST
No, it doesn't. 
It's working now.
Comment 5 JW 2006-11-06 17:50:00 EST
But wait a minute!

The new patch leaves the tm_dst element at zero.
That might work when you test with transition from daylight saving to
non-daylight saving but I don't think it will work in the other direction.

It must be set to -1.

Also, what sort of patch is it that just comments out a line?  Surely the aim is
to remove bugs not just leave them in as a comment.  Please delete the line if
it is wrong.  Why leave a wrong line in as a comment?
Comment 6 Marcela Mašláňová 2006-12-11 09:39:29 EST
Fixed in FC-6 update, rawhide.

Note You need to log in before you can comment on or make changes to this bug.