Support relaying a datetime to start commands from tronctl

[jfongatyelp]

Today, tronctl start and tronctl backfill commands accept date-only parameters because they use the parse_date helper which only knows the %Y-%m-%d format.

However, this meant t hat we would never be able to initiate a run with a custom start time, e.g. to backfill a sub-daily (eg hourly) job.

The start support in the api, however, doesn't seem to reduce the run_time param to just a date:
resource.py's render_POST -> requestarg's get_datetime -> DATE_FORMAT which includes time ("%Y-%m-%d %H:%M:%S")

This PR expands the supported formats in parse_date to some common datetime formats. I also took the opportunity to move it to our shared cmd_utils rather than leaving it just in tronctl itself, and added some dumb tests.

This change won't help tronctl backfill generate more than daily schedules, but at least allows folks to work around that limitation and send their own datetime thru tronctl start.

[KaspariK]

I think one catch, that's probably not a big deal, is backfill will also use this expanded date parser, right? So we'll accept datetimes but the command will stay date-based (like, timestamps are stripped in dryrun output, but real runs still submit the full datetime to the API).

Not saying anyone would do this but this would generate 1 run:
tronctl backfill job --start-date 2026-07-08T18:00 --end-date 2026-07-09

And this would generate 2:
tronctl backfill job --start-date 2026-07-08 --end-date 2026-07-09

[jfongatyelp]

Ah interesting that's a good call, I was just assuming because of the start date range generator, that would strip whatever times the user passed in to backfill. Unfortunate! I can just add an allow_datetime toggle to `parse_date` and use that for `start` but off for `backfill` as a quick fix, but if we get around to adding more schedule support for backfill we can start using date times again.

…

On Fri, Jul 10, 2026, 12:22 PM Kevin Kaspari ***@***.***> wrote: *KaspariK* left a comment (Yelp/Tron#1104) <#1104 (comment)> I think one catch, that's probably not a big deal, is backfill will also use this expanded date parser, right? So we'll accept datetimes but the command will stay date-based (like, timestamps are stripped in dryrun output, but real runs still submit the full datetime to the API). Not saying anyone would do this but this would generate 1 run: tronctl backfill job --start-date 2026-07-08T18:00 --end-date 2026-07-09 And this would generate 2: tronctl backfill job --start-date 2026-07-08 --end-date 2026-07-09 — Reply to this email directly, view it on GitHub <#1104?email_source=notifications&email_token=AAQFO6PF3NY4UNWNUCKCCP35EE7AJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHA3TKNZZGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4938757950>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQFO6KYDH32UMSUPJFYYBL5EE7AJAVCNFSNUABCKJSXA33TNF2G64TZHM4DSOJXG4YTWSLTON2WKOZUHA2DEMBXGM2TEMFBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAQFO6MJJDPBX35RYXKRY3D5EE7AJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHA3TKNZZGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AAQFO6IY62764B54C2UFOID5EE7AJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHA3TKNZZGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>