Fix.6701.scheduler time zone change bug#6719
Conversation
6a49f26 to
2ad10fe
Compare
| TIME_ZONE_LOCAL_UTC_OFFSET_HOURS = TIME_ZONE_LOCAL_UTC_OFFSET[0] | ||
| TIME_ZONE_LOCAL_UTC_OFFSET_MINUTES = TIME_ZONE_LOCAL_UTC_OFFSET[1] | ||
|
|
||
| TIME_ZONE_LOCAL_INFO = { |
There was a problem hiding this comment.
This is only used in cylc.flow.data_store_mgr.DataStoreMgr.generate_definition_elements which seems to be for fields which are not updated. @dwsutherland might wish to comment on whether this safe.
There was a problem hiding this comment.
I can't think why this information is needed in the data store/GQL API at all.
There was a problem hiding this comment.
Yes, the time zone is recorded on the workflow object from TIME_ZONE_LOCAL_INFO:
cylc-flow/cylc/flow/data_store_mgr.py
Line 697 in d5ac2e2
That will only be reread from TIME_ZONE_LOCAL_INFO on start/restart and reload...
Does TIME_ZONE_LOCAL_INFO also get updated on reload?
The job nodes just get passed the time by the events or job manager.
There was a problem hiding this comment.
That leads to a real possibility that the time zones in the GUI will be wrong on DST change? I think I should create an "investigate this" ticket.
There was a problem hiding this comment.
What is the use case for having in the GraphQL API the local system time zone on scheduler start (except not when the workflow is running in UTC mode)? Note this is not the cycle point time zone
|
N.B. will conflict with #6640 |
| TIME_ZONE_LOCAL_UTC_OFFSET_HOURS = TIME_ZONE_LOCAL_UTC_OFFSET[0] | ||
| TIME_ZONE_LOCAL_UTC_OFFSET_MINUTES = TIME_ZONE_LOCAL_UTC_OFFSET[1] | ||
|
|
||
| TIME_ZONE_LOCAL_INFO = { |
There was a problem hiding this comment.
I can't think why this information is needed in the data store/GQL API at all.
|
@wxtim Can you please explain the bug in the PR description |
f055f41 to
56be9d1
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
Credit to @MetRonnie for working out why Mac was behaving differently: Python on Mac doesn't appear to require |
ccaf3be to
1bc013f
Compare
|
@hjoliver - Review Poke |
|
@hjoliver Review poke |
|
@hjoliver Review poke |
fa4bfef to
6384348
Compare
response to review rewrote test in a less resource intensive way make the set_tz fixture more generic
* Modernise docstring.
Co-authored-by: Ronnie Dutta <61982285+MetRonnie@users.noreply.github.com>
6384348 to
08379ac
Compare
Closes #6701
The first time the scheduler loads
cylc.flow.wallclockthe constantsTIME_ZONE_STRING_LOCAL_BASICandTIME_ZONE_STRING_LOCAL_EXTENDEDare populated for the lifetime of the scheduler. This means that the time zone returned byget_time_stringwill remain the same, even if the time it adds to the time zone label changes time zone.For example a scheduler started in UK winter will always return
date_time.strftime(date_time_format_string) + 'Z'. If the clocks subsequently go forward, the time recorded for local time09:00+01:00will be09:00Zwhich is equivelent to10:00+01:00. The consequence is that the database table will record thetime_submitfield as nearly an hour after thetime_submit_exitfield.This bug is particularly noticable in Cylc Review where the following was observed:
i.e. the task has submitted 22 minutes in the future!
Check List
CONTRIBUTING.mdand added my name as a Code Contributor.setup.cfg(andconda-environment.ymlif present).?.?.xbranch.