Ansgar Burchardt <ansgar@43-1.org> wrote:
What's "upstream"? I thought you were the top maintainer; if not, for
my curiosity's sake, who is?
I look for the behaviour at:
http://www.opengroup.org/onlinepubs/9699919799/utilities/at.html#tag_20_05_05
There is actually no specification for `day_of_week' interpretation,
but I guess it should work in a similar fashion to `month_name', so
I project the behaviour on `day_of_week' ("no year is given" becomes
"no week is given", "current month" becomes "current day", "next year"
becomes "next week").
Two specifications are given.
One specification is under "date": with no year, if month is less than
the current, next year is taken. Example: executed on 13th Apr, `10:00
Apr 12' should choose the current year (Apr is not less than the current
month April). Similarly `0900 Sun' later on Sunday could be equivalent
to `0900 today' (with all consequences).
Second specification is after "%token day_number" (in the grammar) is
merely less specific: with no year, current year is chosen if date+time
is not earlier, and next year if date+time has occurred and month is
not the current month; what this does not specify is when the date+time
has occurred and month *is* the current month. Example: `10:00 Apr 12'
is unspecified; similarly `0900 Sun' could be unspecified, too.
Before the grammar it reads: "This formal syntax shall take precedence
over the preceding text syntax description."; but does it include
semantics, too? I don't know. Is there a Usenet group discussing
POSIX Standard?
As for implementations I mentioned in my original report, their behaviour
differs.
Solaris:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/cron/at.c
l. 329+
Nothing interesting happens after yyparse(). The behaviour (for month-year)
is defined entirely in:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/cron/att1.y
l. 159+
after "MONTH number": if (month < current_month) year++.
When executed on Tuesday, April 13th 2010, at 13:13:
`0900 Mar 13' = 2011-03-13 9:00
`0900 Mon' = 2010-04-19 9:00
`0900 Apr 12' = ERROR (2010-04-12 9:00)
`0900 Apr 13' = ERROR (2010-04-13 9:00)
`0900 Tue' = ERROR (2010-04-13 9:00)
(Scheduling is based solely on month_name and current_month; and
day_of_week and current_day_of week.)
OpenBSD:
Date is parsed in function month():
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/at/parsetime.c?annotate=1.17
l. 500+
Further year adjustment is made in assign_date() l. 457:
if (month < current_month || (month == current_month && day < current_day))
year = current_year + 1
`0900 Mar 13' = 2011-03-13 9:00
`0900 Mon' = 2010-04-19 9:00
`0900 Apr 12' = 2011-04-12 9:00
`0900 Apr 13' = ERROR (2010-04-13 9:00)
`0900 Tue' = ERROR (2010-04-13 9:00)
(Scheduling is based on month+day and current_month+current_day
when month+day given; and on day_of_week and current_day_of_week
when day_of_week given.)
Note: time of day is not involved in either implementation.
To summarize: Solaris implementation uses "resolution" of one month
when month is given, and one day, when day_of_week is given; BSD uses
"resolution" of one day for both cases. By "resolution" I mean that
current period (year, week) is chosen if specified time falls into current
slot and is in the past, and next period is chosen if the specified time
falls into one of the previous slots.
I actually have no preference between the two, but it seems to me there
should be some reasonable period of "error"; one day is good, one minute
would not. I would prefer `at 13:11 Apr 13' issue an error rather
than move the job one year later, and for the same reason `at 0900 Sun'
should issue an error, too; (also, for minumum confusion, it should
behave the same as `at 0900 today' and `at 0900 Apr 11', when executed
on Apr 11 2010).
One final thing: I haven't delved deep into this yet, but there will be
differences handling the increment (when should we apply fixups, before
or after applying increment?): on Solaris `1313 Apr 12 + 1 year' will be
in 2011; with current `at' it'll be 2012; BSD doesn't parse this at all.
Sorry, for a long post, I meant to be helpful.
Regards, Stan.