rose date: -c AND positional argument

[oliver-sanders]

rose date behaves strangely when date times are provided, both via the -c option and as a positional argument.

This is really an error as the same argument has been provided twice in two different ways, however, the old version apparently handled this case.

Posted on element - https://matrix.to/#/!AmOqCkEcQUtDwnxASW:matrix.org/$168076870358399pQngS:matrix.org?via=matrix.org

Diagnosing a user Cylc 8 problem today, turned out to be caused by a rose date command constructed from various Jinja2 variables in a coupled climate workflow.

rose date -c ... means get the cycle point from ROSE_TASK_CYCLE_TIME in the environment

In Rose 2019 if I use BOTH -c and a cycle point on the command line, the command line overrides the option, and the correct value is printed.

In Rose 2 if I use BOTH, the command prints bollocks. It works correctly if I use either/or separately.

$ export ROSE_TASK_CYCLE_TIME=30000101T0000Z
$ rose version
Rose 2019.01.3 (/scale_wlg_persistent/filesets/opt_nesi/share/Rose/2019.01.3)
$ rose date -c --calendar=360day --print-format='%Y,%m,%d,%H,%M,%S' 40000101T0000Z
4000,01,01,00,00,00
...
$ rose version
rose 2.0.2
$ rose date -c --calendar=360day --print-format='%Y,%m,%d,%H,%M,%S' 40000101T0000Z
WARNING: "rose date" is deprecated, use the "isodatetime" command.
-%Y,%0,%360000,%H,%0,%S # <------- QUE?!

We could either:

1. Raise a helpful error.
2. Replicate the 2019 behaviour.

[hjoliver]

IMO raise an error. I doubt that many rely on the old behaviour (although I obviously ran into one case), but it has the potential to cause bugs (ambiguous) and is an easy one to fix if users encounter the new error message.