You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in the nomad google group thread, the output of running periodic job can become a little confusing because of the TZ. Bringing back the example of the thread: If I need to run a job every day at 16:00 hours UTC and knowing that my nomad server is running with UTC TZ I imagine that if I do this I'll get the job running in that TZ:
When I running the job from my local machine that it's not UTC I'll get:
nomad run some-periodic-job.nomad
Job registration successful
Approximate next launch time: 2016-04-08 16:00:00 -0430 VET
And that's not what I want. I end up running the job like this just to be sure I was setting it correctly even though it was set correctly:
TZ=UTC nomad run some-periodic-job.nomad
Job registration successful
Approximate next launch time: 2016-04-09 16:00:00 +0000 UTC
As @dadgar said "It may make sense to enforce the TZ as UTC on server side and then the client can make a similar correction." for that reason I'm filing the issue.
Thanks!
The text was updated successfully, but these errors were encountered:
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Nomad version
Nomad v0.3.1
Issue
As described in the nomad google group thread, the output of running periodic job can become a little confusing because of the TZ. Bringing back the example of the thread: If I need to run a job every day at 16:00 hours UTC and knowing that my nomad server is running with UTC TZ I imagine that if I do this I'll get the job running in that TZ:
When I running the job from my local machine that it's not UTC I'll get:
And that's not what I want. I end up running the job like this just to be sure I was setting it correctly even though it was set correctly:
As @dadgar said "It may make sense to enforce the TZ as UTC on server side and then the client can make a similar correction." for that reason I'm filing the issue.
Thanks!
The text was updated successfully, but these errors were encountered: