Support for truncated ISO-8601 datetimes?


pretty much all my workflows (presumably same as most weather and climate users) have cycle points of the form…


for climate workflows, the cycle points almost always fall at midnight on the 1st of the month, i.e. ...01T0000Z.

just wondering how possible it would be to make cylc interpret truncated datetimes? so for example…

199901 <---> 19990101T0000Z

or even…

1999 <---> 19990101T0000Z

just wondering!



cycle points almost always fall at midnight on the 1st of the month

If it’s almost you might find it tricky. If it’s actually always you can set flow.cylc[scheduler]cycle point format. I think that in your case CCYYMM will achieve what you want.

If you can’t use this, can you give me more context about where you’d want to use the truncated format?

1 Like
1 Like

Is there a specific case where using a truncated datetime is not working for you? In general, Cylc does indeed support truncated datetimes.

1 Like

Jonny’s referring to reduced precision datetimes (i.e. truncated from the right) rather than what Cylc refers to as truncated datetimes (i.e. truncated from the left).

The [scheduler]cycling point format is the way to go for this case.

1 Like

Ok yes, we should be clear about the terminology. But regardless, Cylc interprets 2000 as 20000101T0000Z in most circumstances without having to set the cycle point format. Setting the cycle point format has the additional effect of printing all cycle points in that format and means you cannot use precision greater than the smallest unit in the format

1 Like

thanks a lot for all the information @MetRonnie & @oliver.sanders!

the application that i’d be interested in setting up and/or finding out more about is using the command line cylc tools. i probably should’ve said that in my original post! :stuck_out_tongue: e.g. at the moment i use commands like this a lot (already using the assumed runN shorthand before the //)…

cylc log u-cy821//19780101T0000Z/fcm_make_lfric

and it would be handy to be able to type…

cylc log u-cy821//197809/fcm_make_lfric

… for example.

i think i probably don’t want to start messing around with the format of the dates in the workflows themselves since my work is so highly collaborative and i don’t want to make unilateral decisions for other users.

basically i was wondering if there is a way of making the cylc command line arguments assume that something happens at 01T000Z or even 0101T0000Z unless told otherwise!

hope that makes sense!



That’s not possible. However, you can use bash auto completion:

1 Like

Ah unfortunately cylc log (aka cylc cat-log) is a special case - the cycle point in the ID you type has to match the job log file path (but as Dave mentioned, it can be autocompleted).

But commands like cylc hold, cylc trigger etc. accept partially specified cycles e.g.

cylc hold u-cy821//1978-09/fcm_make_lfric

(note you have to use the dash between the year and month)

1 Like

oh cool, didn’t know this!

it’s not working for me out of the box for some reason though :thinking:

i’ll look into it, thanks @dpmatthews

thanks @MetRonnie,

good to know! playing around with this, i’ve found that this works (as you mentioned)…

cylc tr u-cy821/runN//1978-09/install_ainitial

and this one too…

cylc tr u-cy821/runN//19780901/install_ainitial

but this one doesn’t…

cylc tr u-cy821/runN//197809/install_ainitial

why does my first example above need a dash between 1978 and 09?

working now! thanks to @hilary.j.oliver!

for future ref…

cylc get-resources cylc-completion.bash <path-to-copy-file>

then put this in your .bashrc or equivalent…

if [[ $- =~ i && -f /path/to/cylc-completion.bash ]]; then
    . /path/to/cylc-completion.bash


1 Like

I think it’s because that’s interpreted as the year 197809 rather than September 1978

1 Like

ah ok, makes sense, even if that is something of a sci-fi date! :slight_smile: