Description of problem: At allows the entry of nonsensical date formats such as MMDDYY. Version-Release number of selected component (if applicable): at-3.1.10-11.fc7 How reproducible: Always Steps to Reproduce: 1. echo | at 07:00 2007-11-30 2. echo | at 07:00 113007 3. echo | at 2007-11-30 07:00 Actual results: 1. works 2. works 3. syntax error Expected results: 1. should work 2. should NOT work 3. should work Additional info: The first format should work but is a bit weird because of the ordering of the odd date and time components. The third format should work because the date and time components are in the most logical order (most significant to least significant, left to right). The second format should not work. Nobody in their right mind would ever arrange a date into month-day-year; it would be as sensible as denoting one hundred and five as 015. Ironically "at" prints out the parsed date in order as specified by current locale, yet refuses to parse date time which is in current locale arrangement! With a small amount of effort this extraordinarily error-probe confusing and plain ridiculous date specification could be eliminated once and for all. Only one country uses the MMDDYY format, so a change shouldn't be that difficult.
_At_ allows fairly complex time specifications, extending the POSIX.2 standard. That means the author of _at_ wrote some POSIX compliant grammar and the date is print out in the format of locales. I can't wrote grammar for all locales.
> I can't wrote grammar for all locales. That certainly make quite a hilarious play on the word "grammar". Well done! It is entirely possibly to do the reverse locale translation. Given that the locale defines a 1-to-1 relationship between actual date/time and a presentation format why not take advantage of it and allow the reverse? It is plain crazy that "at" spits out the resultant date in posix or iso format, yet refuses to accept posix or iso as input.
_at_ use on his output _date_ because it's needed local time. I'm ready to examine some patch from you.
At time+date specification is always in the format [timespec] [dayspec] [increment]. This has to be maintained for backwards compatibility. Perhaps there could be a new option which would allow date specification in other formats but it is not a priority. Feel free to write a patch and send it to at upstream. http://packages.debian.org/etch/at