New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes #36418 - Honor TZ in datetime normalizer #369
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it fix the issue?
hammer command TZ:
$ date
Fri May 19 13:24:00 UTC 2023
Browser timezone: Prague; current time 15:24:00
$ hammer job-invocation create --job-template "Run Command - Script Default" --organization-id "1" --location-id "2" --inputs command=date --search-query "nuka.helole.com" --start-at "2023-05-19 16:24:00"
$ Job invocation 28 created
$ hammer job-invocation info --id 28
$ ID: 28
Description: Run date
Status: queued
Success: N/A
Failed: N/A
Pending: N/A
Missing: 0
Total: N/A
Start: '2023-05-19 18:24:00 +0200'
Randomized ordering: false
Job Category: Commands
Mode: future
Time to pickup:
Hosts: []
When I log in to check the job invocation list, I see that job will be run in 3 hours instead of 1 hour.
UPD: I think it works properly already? I mean, I'm in UTC timezone running hammer command to schedule something which should happen in 3 hours. And it will be run in 3 hours. If I want the command to be run in 1 hour (relative to the server's timezone), I'd need to explicitly specify the timezone, no?
Looking at the BZ, I think there are two ways to deal with that:
|
Damn... Is the BZ about hammer and server being in the same TZ?.. |
I think it is about the fact that unless you explicitly include a time zone information in the time string, hammer will assume it is in utc, ignoring the TZ of machine where hammer runs, machine where server runs and TZ the user in Foreman has configured. Timezones are hell. Verbose & debug output of hammer looks correct, whatever dynflow gets seems correct as well
16:24 UTC is 18:24 CEST (+02:00) What dynflow sees
It seem ok all the way up until the ui tries to display it? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry, @adamruzicka, wrong testing. This patch indeed seems to fix the issue.
No description provided.