Cylc-flow: clock-triggers relative to a different time zone?

[hjoliver]

Apparently there's a requirement at BoM to support clock-triggers in a timezone different to that of the suite, e.g. (presumably) if observing stations of some kind in another state report on local time, but the suite is running in UTC mode.

[matthewrmshin]

Is this really necessary? We have survived long enough processing data coming from all over the world!

[hjoliver]

Well, I'll try to find out...

[hjoliver]

From Xiao at BoM:

Hi, Hilary
I checked with Joan, looking at the SMS include files, our regional systems use local clock, and other systems Use UTC. The problem may not be in observation extraction, more likely in inter suite dependency.
< Suite_G>:A[PT6H] => B
This assume that suite_G and this suite has the same time clock. How do you express this if suite_G uses UTC, and this Suite uses local time?
Thanks
Xiao

[matthewrmshin]

In which case, it is worth finding out how this is done in SMS currently.

(We may need to change the title of this issue, if it is actually about inter-suite dependency instead of clock trigger.)

[hjoliver]

Referring back to Xiao...

[ColemanTom]

Currently SMS doesn't actually trigger jobs for ACCESS-R based on local time clock triggers. It spawns a task/job/whatever you call them which sleeps until it is time to run. I imagine this is more in the "nice to have" category, but it could keep doing the sleep approach. This is done for the regional model so that it always starts at say 11am Melbourne time as forecasters don't want to wait an extra hour in winter or something like that. But it couldn't go an hour earlier because that would be before the actual model start time.

There are ways in SMS to do this without following the sleep approach, but sleeping is easy. I imagine Cylc could do it the same way as SMS could. Spawn a task, it checks what UTC time would be the correct local time, then adjust a time trigger on the real task to reflect the local time adjustment.

[hjoliver]

@ColemanTom - thanks for the input. We can certainly use the sleep method already, but if there's a genuine requirement here we might able to put in something more elegant.

@matthewrmshin - it might be possible to solve this problem (albeit low priority until BoM is fully on board) either by TZ-aware clock-triggers or TZ-aware inter-suite triggers, since it sounds like there's always another suite involved (i.e. you clock-trigger a task that then interacts with another suite running on a different TZ)...

[hjoliver]

OK I think it's clear (another email from Xiao backs up Tom's description) that SMS doesn't have built-in cross-timezone capability and that BoM currently does what it needs with sleeping tasks, which we can also do ... so I can't see this being a show-stopping requirement. On that basis, let's park this issue for now under the "some day" milestone to revisit in the future if need be.

[matthewrmshin]

Although I think I can now just about understand the requirement, figuring out how to deal with daylight saving time change in different suites (when clock triggers and inter-suite dependencies are expressed in time intervals) is still a puzzle that I have no idea how to solve.

[ColemanTom]

I thought I should bump this. When the xtriggers item has a new repository made as per https://github.com/cylc/cylc/issues/3116, this Issue should be migrated over to it as xtriggers can handle this fairly well (I'm happy to implement it in xtriggers anyway).

[hjoliver]

Closing as wontfix for now, unless @ColemanTom comes back to #3471 at some point.