hey,
pretty much all my workflows (presumably same as most weather and climate users) have cycle points of the form…
19990101T0000Z
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!
cheers,
jonny
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?
Is there a specific case where using a truncated datetime is not working for you? In general, Cylc does indeed support truncated datetimes.
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.
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
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! 
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!
cheers,
j
That’s not possible. However, you can use bash auto completion: https://cylc.github.io/cylc-doc/8.2.1/html/reference/changes.html#bash-completion
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)
oh cool, didn’t know this!
it’s not working for me out of the box for some reason though 
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
fi
I think it’s because that’s interpreted as the year 197809 rather than September 1978
ah ok, makes sense, even if that is something of a sci-fi date!