semaphore icon indicating copy to clipboard operation
semaphore copied to clipboard

Cron at UTC time instead of local time

Open bverkron opened this issue 2 years ago • 4 comments

I have a cron for a task setup as follows (should be 1am local time) and it's running at 6pm local time, which seems to indicate it's running at 1am UTC

image

image

image

Being that the UI is in my local time I would expect the cron to match that (or vice versa to indicate everything is in UTC).

Is there a setting behind the scenes for the time zone that I can set? I don't see anything in the doc or UI.

bverkron avatar Oct 06 '22 01:10 bverkron

Possibly related to https://github.com/ansible-semaphore/semaphore/issues/974 ? Not sure if it's the same root cause (looks like DB timezone maybe?) or if it's something else.

bverkron avatar Oct 06 '22 01:10 bverkron

I would consider this a really low priority issue (not even sure if it's considered a "bug" or not) being that once you know this you can just account for it in the cron schedules by bumping them by the offset.

bverkron avatar Oct 06 '22 01:10 bverkron

Have you found reasons/solution?

gromavic avatar Jan 10 '23 13:01 gromavic

Is there any progress on this? The issue seems to be that the container timezone is always set to UTC. Other images usually allow the timezone to be set in a container using something like the TZ environment variable or mapping /etc/timezone or /etc/localtime from the host to the container - Both these methods don’t currently work and the container remains in UTC.

Also - There’s currently no date/time or information in the UI that cron scheduled tasks will run against UTC. The user may expect that the task runs in their local timezone and so configures accordingly. This may cause further issues if the task then actually runs at later unexpected times.

n1nj4888 avatar Jun 02 '23 00:06 n1nj4888

I recently ran into the same issue when using Ansible Semaphore in a Docker container.

I was able to fix it by sharing my host machines timezone settings via a volume and then restarting.

services:
  semaphore:
    image: semaphoreui/semaphore
    volumes:
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
# ...

rmtsrc avatar Jun 11 '23 15:06 rmtsrc

I recently ran into the same issue when using Ansible Semaphore in a Docker container.

I was able to fix it by sharing my host machines timezone settings via a volume and then restarting.

services:
  semaphore:
    image: semaphoreui/semaphore
    volumes:
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
# ...

Sadly passing TZ mounts or env var doesn't change container timezone.

xpliz avatar Jun 18 '23 09:06 xpliz

Just leaving some info here that worked for me.

I had to actually export /etc/localtime in both containers, semaphore and the DB. This way, cron actually respects my timezone.

Jojonintendo avatar Jun 27 '23 08:06 Jojonintendo

I would consider this a really low priority issue (not even sure if it's considered a "bug" or not) being that once you know this you can just account for it in the cron schedules by bumping them by the offset.

I'll make a case for it being literally a bug. User puts in a cron entry and it runs 7 hours early, that's unexpected. UI doesn't say "Cron (in UTC)" so it's reasonable for the user to expect it to be in local time. Having the user calculate the time in UTC is a workaround, but is bad UX. Having the user have to go dig through Github Issues to find the fix is also bad UX. Especially when "how to set TZ in docker container" google searches point you towards setting the TZ environment variable, and at that point all other commands on the system seem to show a local timezone.

Some possible fixes:

  • Expose /etc/localtime and /etc/timezone into docker containers in docker compose file.
  • Have the UI say "Cron (in UTC)".

linsomniac avatar Aug 01 '23 20:08 linsomniac

Pull request: https://github.com/ansible-semaphore/semaphore/pull/1730

cbrookins avatar Jan 31 '24 19:01 cbrookins

With the merged PR you should be able to provide the TZ environment variable to set the right timezone.

tboerger avatar Feb 02 '24 08:02 tboerger

We just did an update and can confirm that it seems to be using the correct timezone. Thanks!

linsomniac avatar Feb 03 '24 01:02 linsomniac