bin/53986: at(1) HH:MM fails to assume next day

[naddy%mips.inka.de@localhost]

>Number:         53986
>Category:       bin
>Synopsis:       at(1) HH:MM fails to assume next day
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 16 16:30:00 +0000 2019
>Originator:     Christian Weisgerber
>Release:        
>Organization:
>Environment:
>Description:
I ran into an ancient at(1) bug on FreeBSD and OpenBSD, but NetBSD shares the same code.

The at(1) man page says:
at allows some moderately complex time specifications.  It accepts times of the form HHMM or HH:MM to run a job at a specific time of day.  (If that time is already past, the next day is assumed.)

This only works if the hour is past.  It fails if we are still within the same hour but the minutes are past.

>How-To-Repeat:
$ date
Sat Feb 16 16:56:28 CET 2019
$ echo dummy | at 15:00
Job 42 will be executed using /bin/sh
$ echo dummy | at 16:00
at: trying to travel back in time

>Fix:
Index: parsetime.c
===================================================================
RCS file: /cvsroot/src/usr.bin/at/parsetime.c,v
retrieving revision 1.19
diff -u -r1.19 parsetime.c
--- parsetime.c 18 Jan 2009 01:02:31 -0000      1.19
+++ parsetime.c 16 Feb 2019 16:13:56 -0000
@@ -405,7 +405,8 @@
         * if we've gone past that time - but if we're specifying a time plus
         * a relative offset, it's okay to bump things
         */
-       if ((sc_tokid == TOKEOF || sc_tokid == PLUS) && tm->tm_hour > hour) {
+       if ((sc_tokid == TOKEOF || sc_tokid == PLUS) && (tm->tm_hour > hour ||
+           (tm->tm_hour == hour && tm->tm_min > minute))) {
                tm->tm_mday++;
                tm->tm_wday++;
        }