at does not respect the [.ss] portion of the -t option

Patch compiles successfully and works as expected.

The attachment "0001-Allow-seconds-in-t-option.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Status changed to 'Confirmed' because the bug affects multiple users.

I can also confirm this behavior

$ at -t 202012140849.27
warning: commands will be executed using /bin/sh
at> date > /tmp/testme
at> <EOT>
job 2 at Mon Dec 14 08:49:00 2020

$ cat /tmp/testme
Mo 14. Dez 08:49:00 CET 2020

So it announces AND executes ignoring the seconds.

That code is in since 3.1.11 by upstream which was the time that -t was added.

Seconds are only used in "-t option" -> "posixtime" -> "posixtime_time_parse" which is called before seconds are dropped intentionally.

This isn't a regression it always was a missing detail from upstream that never worked.
Note: this is the same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792040
Adding that as tracker.

The change got now implemented by upstream in:
https://salsa.debian.org/debian/at/-/commit/15ee22de9dfd67d9c97404302623a9d45ce887a2

This was meant to be in 3.1.24, but that got never released.
It got into 3.2.0 which is a bigger step and not yet packaged/uploaded for Debian/Ubuntu (there is 3.2.1 already).

I'll subscribe paride who was recently merging "at" to consider getting this updated.

This bug was fixed in the package at - 3.1.23-1.1ubuntu2

---------------
at (3.1.23-1.1ubuntu2) hirsute; urgency=medium

  * d/patches: add 03-do-not-drop-seconds.patch (cherry-pick).
    When calculating time for the job, do not drop seconds. (LP: #1464051)

 -- Paride Legovini <email address hidden> Tue, 15 Dec 2020 12:01:14 +0100

Affects Focal as well; would be awesome to backport this.

Please could you clarify the use case that requires sub-minute precision? Without an explanation of this, I don't see how an SRU is justified here.

Hi Robie,

Using at with `-t` is well-defined and used. From the manpage of at from focal:
-t time run the job at time, given in the format [[CC]YY]MMDDhhmm[.ss]

But that doesn't work w/o this patch, that is, [.ss] is never respected. If I were to schedule a one-time job where I need the sub-minute precision, I could never get that done even though "at" says (and documents) that it's indeed possible.

With this patch (and SRU), that [.ss] is respected and "at" works again as documented. Let me know if you need more details. Thanks for taking a look.

I discussed this further with Utkarsh. Since there isn't currently a high impact use case and we have so few people affected since 2015, I'm going to reject this SRU on the basis that it doesn't meet the bar for risking regression and download/install bandwidth/time for existing users. On this basis, I'm marking the SRU tasks Won't Fix. Hirsute is fixed, and so the next LTS will also have this fixed.

This decision can be revisited if a high impact use case is put forward, and affected users volunteer to do the necessary QA.

An upload of at to groovy-proposed has been rejected from the upload queue for the following reason: "See previous comment".

An upload of at to focal-proposed has been rejected from the upload queue for the following reason: "See previous comment".