Description of problem: The t_option patch applies wrong daylight-saving value to time Version-Release number of selected component (if applicable): at-3.1.8-82 How reproducible: Always 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); } OR 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.
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.
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.
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.
No, it doesn't. It's working now.
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?
Fixed in FC-6 update, rawhide.