Degenerate cycle point bug?

[hjoliver]

Describe the bug

The traceback that I accidentally/misleadingly posted in the description of #3369 still suggests a bug:

[cylc]
    UTC mode = True
    cycle point format = %Y%m%dT%HZ 
[scheduling]
    initial cycle point = 2020
        [[graph]]
             P1Y = "foo"  # (or P1D or whatever)

This validates OK with any combo of UTC mode = True and Z on the cycle point format.

But at runtime, it fails with SequenceDegenerateError if the cycle point format ends in Z but the server does not have UTC mode = True.

...
2019-09-26T16:21:17+12:00 INFO - Final point: None
2019-09-26T16:21:17+12:00 INFO - Cold Start 20200101T00Z
2019-09-26T16:21:17+12:00 ERROR - R/20200101T00Z/P1Y, point format %Y%m%dT%HZ: equal adjacent
        points: 20200101T00Z => 20200101T00Z.
        Traceback (most recent call last):
          File "/home/oliverh/cylc/cylc-flow/venv/lib/python3.7/site-packages/cylc/flow/scheduler.py", line 253,
        in start
            self.run()
          File "/home/oliverh/cylc/cylc-flow/venv/lib/python3.7/site-packages/cylc/flow/scheduler.py", line 1519,
        in run
            if self.pool.release_runahead_tasks():
          File "/home/oliverh/cylc/cylc-flow/venv/lib/python3.7/site-packages/cylc/flow/task_pool.py", line 284,
        in release_runahead_tasks
            point = sequence.get_next_point(point)
          File "/home/oliverh/cylc/cylc-flow/venv/lib/python3.7/site-packages/cylc/flow/cycling/iso8601.py", line
        544, in get_next_point
            self._check_and_cache_next_point(point, next_point)
          File "/home/oliverh/cylc/cylc-flow/venv/lib/python3.7/site-packages/cylc/flow/cycling/iso8601.py", line
        554, in _check_and_cache_next_point
            next_point, point
        cylc.flow.exceptions.SequenceDegenerateError: R/20200101T00Z/P1Y, point format %Y%m%dT%HZ: equal adjacent
        points: 20200101T00Z => 20200101T00Z.
2019-09-26T16:21:17+12:00 CRITICAL - Suite shutting down - R/20200101T00Z/P1Y, point format
        %Y%m%dT%HZ: equal adjacent points: 20200101T00Z => 20200101T00Z.
2019-09-26T16:21:18+12:00 INFO - DONE
SequenceDegenerateError: R/20200101T00Z/P1Y, point format %Y%m%dT%HZ: equal adjacent points: 20200101T00Z => 20200101T00Z.

Reproduced on master and 7.8.x (probably a long-standing bug).

UTC mode affects the server clock, and log timestamps etc., but not cycle points.

Seems to me, we should be able to have the clock running on local time, but UTC cycle points.

[matthewrmshin]

See also #2324 for the proposed intention to change the default behaviour:

• Cycle point time zone should be Z by default so suite behaviour should be unaffected by DST changes.
• Switch off UTC mode, i.e. log timestamp, etc will be local time.

[hjoliver]

(Put to someday as no one has actually complained of hitting this problem ... so its low priority).

[MetRonnie]

Some observations (with UTC mode = False, system timezone BST (+01:00)):

cycle point format = %Y%m%dT%H%MZ (strftime syntax):

• SequenceDegenerateError raised
• Initial cycle point is treated as UTC (2020-01-01T00:00Z)

cycle point format = CCYYMMDDThhmmZ (ISO 8601 syntax):

• Runs ok, no error
• Initial cycle point is treated as local time zone (2019-12-31T23:00Z, i.e. 2020-01-01T00:00+01:00)

Update: if the initial cycle point is specified to be 2020-01-01T00:00Z, the stftime syntax still errors while the ISO syntax still runs ok.

[MetRonnie]

Another thing: the documentation is a bit unclear about how the cycle point format works with cycle point time zone. Here is the behaviour I have observed (when using the ISO 8601 syntax):

• The time zone in cycle point format is used for writing/dumping cycle points only, whereas the cycle point time zone is used for both inferring cycle points inputted without time zone info and writing/dumping
• Writing/dumping uses the cycle point format time zone in preference to the cycle point time zone (i.e. if both are specified the cycle point time zone will be used for inferring time zones only)