How do I configure Portainer to use the local time?

[choonchernlim]

Typically, I set TZ environment variable in every container in my docker-compose.yml, but Portainer doesn't seem to honor that.

services:
  portainer:
    image: "portainer/portainer"
    privileged: true
    ports:
     - "9000:9000"
    environment:
      TZ: "America/Menominee"
    ...

Here's the timestamp on server log:-

portainer    | 2017/06/03 15:20:24 Starting Portainer on :9000
jenkins      | Jun 03, 2017 10:20:56 AM Main deleteWinstoneTempContents ...
nexus        | 2017-06-03 10:21:06,466-0500 WARN  [FelixStartLevel] ...

Both Jenkins and Nexus containers have TZ environment variable set accordingly, and they are displaying the correct local time.

Thank you.

[deviantony]

Portainer uses the default logging library log. Default date and time should be the local system ones: https://golang.org/pkg/log/#pkg-constants

Also, I don't think that the TZ env variable is supported in Portainer image as it's based on scratch. You could try the /etc/timezone workaround:

• container timezone moby/moby#3359

You could also try to bindmount /etc/localtime:/etc/localtime

[choonchernlim]

Bind mount /etc/localtime:/etc/localtime works for me. Thank you.

[nemchik]

Sorry to necro this, but is there any chance that TZ could be supported in the Portainer images?

[deviantony]

What about using the workaround above @nemchik ?

[nemchik]

The volume works, but I'm still interested in TZ if it would be considered.

[deviantony]

Not planned yet as we'd rather keep using the scratch image, we could implement our own log writer instead of using the default and load the TZ from the environment. I'll re-open to track this.

[nemchik]

I appreciate the consideration!

[Diegus83]

I recently installed Portainer in a mac OS host and run into the same issue.
/etc/localtime is a link pointing to /var/db/timezone/zoneinfo/America/New_York
/var is a link to /private/var so Docker complains /private is already shared
The closest I got to make it work was to bind
"Source": "/private/var/db/timezone/tz/2018g.1.0/zoneinfo/America/New_york",
"Destination": "/etc/localtime"
The time in the logs was ok after this but it didn't survived the first reboot of the host.

Anyone found a workaround for mac OS hosts?

Is not a big deal but the time in the logs is about 4hs ahead of my local time.

[andsoitgoes]

Hi everyone - I posted another issue regarding this referenced as 3093, nothing I do following the guides here has worked.

Hoping someone can help figure this out. Using Linux (specifically Raspbian Buster) as the host system.

[ghost]

@deviantony @ncresswell what are our plans for timezone support in Portainer? I know there is a logging extension in the plans which I assume would require support for timezones?..

[sfkpmr]

Any updates on this?

[ghost]

@sfkpmr I can now confirm the next extension will be logging/auditing, which I mentioned previously will likely imply timezone support.

Unfortunately I can't give you an exact ETA on this, as current development efforts are focused on k8s support and an EE build of Portainer (releasing to the public soon). Following the release of these, our focus will be back on extensions.

[auanasgheps]

Seems that binding /etc/localtime:/etc/localtime does not make any difference.
Are you experiencing the same thing?

[brumela]

Seems that binding /etc/localtime:/etc/localtime does not make any difference.
Are you experiencing the same thing?

I can confirm, that it was working some months ago, but after some updates of docker and portainer, it stop working. My system in Debian 10 and portainer is 1.23.2.

[brumela]

Seems that binding /etc/localtime:/etc/localtime does not make any difference.
Are you experiencing the same thing?

I can confirm, that it was working some months ago, but after some updates of docker and portainer, it stop working. My system in Debian 10 and portainer is 1.23.2.

I fix-it with adding ENV variable TZ=Your/Timezone

[taw123]

Not to be a complainer BUT this has been an open issue for 5 years.....

Things that don't work: (don't change from UTC to local zone)

• Can't manually set as INSIDE the container as no bash or sh (for security reasons) (or I would just map the appropriate /usr/share/zoneinfo/)

• Can't set by Bind mount /etc/localtime onto /etc/localtime This is an issue for MANY people on a diverse list of platforms as witnessed in the bug.

• Can't the pass TZ env variable to set time zone given your use of screen / logging

Can someone either look at fixing the ENV support or as was "potentially" offered switch to your own logging solution so we can get accurate Portainer generated timestamps in logs. Thank you for any assistance you can provide. I'd be happy to help as well if you need some dev time. Just seems foolish for such a polished solution. Thanks again.

[spekafl]

Hi, I'm using the alpine version, and not have tzdata installed, that's why doesn't recognize de TZ variable.

For example, in the Dockerfile, add the following lines:

ENV TZ=America/Argentina/Cordoba

RUN apk --no-cache add tzdata && rm -rf /var/cache/apk/*

Works for me.

Best regards!!

[axute]

I also added tzdata, now the time is right.
Have trouble with oauth and expired jwt token.

[keldian]

Hi, I'm using the alpine version, and not have tzdata installed, that's why doesn't recognize de TZ variable.

I don't think any version has tzdata installed. latest doesn't at least.

[kratoz29]

ENV TZ=America/Argentina/Cordoba

RUN apk --no-cache add tzdata && rm -rf /var/cache/apk/*

I literally copy pasted what you just put, and no luck either... I mean, the time is correct in the Portainer itself, but the timestamps are all wrong, and I have tried countless workarounds but no luck... I think it is just impossible, for reference, this is how my Dockerfile looks like:

FROM portainer/portainer-ce:linux-amd64-2.16.2-alpine
#RUN apk add -U tzdata
#ENV TZ=America/Mexico_City
#RUN cp /usr/share/zoneinfo/America/Mexico_City /etc/localtime
ENV TZ=America/Mexico_City
RUN apk --no-cache add tzdata && rm -rf /var/cache/apk/*

[LostOnTheLine]

Since this issue has been going on for so long, & workarounds keep getting worked-out of the system, can I suggest maybe making it an option in the settings within Portainer?

Like in the Host settings or Account/Server settings. A little Logging section with a Use Localtime or UTC (Default) or Custom: ______

I can understand it using UTC as a default as you could have servers spread out & that keeps everything coordinated, but there are also plenty of reasons that's not ideal or even unusable for many. Having it as a UI setting prevents it from being defaut-set because people copy-pasted from a guide or whatever, but still gives a way to change it that makes it clear what it does

[kratoz29]

For real, and this should not be something of Portainer alone, every docker container should be flexible about this.

[MikeFalcor]

Wait...this is STILL not a thing?!?! WTF...

[Nick-Portainer]

Hi!

After some testing for a work around there are two methods we have confirmed to work.

Using /usr/share/zoneinfo, for example

docker run -d -p 9443:9443 --name portainer --restart=always --env TZ=Pacific/Auckland -v /var/run/docker.sock:/var/run/docker.sock -v portainer:/data -v /usr/share/zoneinfo:/usr/share/zoneinfo portainer/portainer-ee:latest noticing the TZ= and set that to your TZ of choice.

The timezone is case sensitive, it must match the directory under /usr/share/zoneinfo

Using localtime.

docker run -d -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer:/data -v /etc/localtime:/etc/localtime portainer/portainer-ee:latest

These two methods will allow you to set your preferred timezone

[jerrywoo96]

When the Display Timestamps is enabled in the logs, does it change the zulu time to localtime?

[Nick-Portainer]

When you set localtime is will use the local time of your host and that's what will show in your logs, so yeah it changes from UTC to your localtime in the Portainer logs

[viperk1]

Nick, the portainer logs themselves will be in the right time zone, but I think a lot of us are asking about the container logs within the portainer ui when you view the logs for a specific container. Nothing I do will change those from Zulu time.

[Yanik39]

Still no fix :D ?
I know few freelancer coders that may help you guys for 5$ :D

[LostOnTheLine]

There are plenty of those same types already wanting this, so it's not something that paying them would do anything to improve except their wallets. The problem isn't that nobody can figure a way to do it, it's that for some reason the root program is set to ignore all time zone conditions & ONLY report times in GMT. I'm sure many could build from source, changing a few things, & make a branch, but nobody want that. We want a way to use the main program with this option. What we need is either A.) Portainer/Docker devs to fix the problem, which they obviously don't see as a problem, or a way to make it work, which isn't about coding skills, but rather about MacGyver skills

[SickProdigy]

Would be nice to change the time in portainer container logs. Have tried everything listed above and nothing.
etc/localtime:/etclocaltime
/usr/localtime/my/country/state:/etc/localtime
tz: my/code

None worked in compose.

[taw123]

Seems move to discussion means bury issue (as was the case with another long standing item push docker compose files from portainer too GitHub).

While I might not LIKE having an issue closed as not to be fixed I DO RESPECT it is their choice as owners oof code what they choose... but this.... this just burying the issue by moving out of bug tracking which it clearly is (lack of respect for TZ settings), is NOT an honorable way to conduct business, and only would inspire another bug to be filed by someone who is unaware of this "silent" decision....

PLEASE reconsider both the "decision" to not address this and the move to turn this into a discussion. I think time to discuss is over we all understand the issue/what can be done to mitigate impact and what CAN'T BE DONE locally to display local TZ timestamps in portainer logs.

Thank you.

[LostOnTheLine]

Seems move to discussion means bury issue (as was the case with another long standing item push docker compose files from portainer too GitHub).

While I might not LIKE having an issue closed as not to be fixed I DO RESPECT it is their choice as owners oof code what they choose... but this.... this just burying the issue by moving out of bug tracking which it clearly is (lack of respect for TZ settings), is NOT an honorable way to conduct business, and only would inspire another bug to be filed by someone who is unaware of this "silent" decision....

So, while I agree that this is something that should be fixed, if it was closed because the developer acknowledged the issue & decided that they did not think it worth their time to fix, which seems like the case here, then keeping it open is not appropriate.

Think of it this way; Your friend takes you to a party at some guy name Portainer's house. There is food to eat & you choose to grab a hamburger. You like the hamburger but wish that it had soy sauce on it. You find a handful of other people who also want soy sauce on their burgers. You all look for soy sauce but don't find any. You ask if there's some soy sauce but the host is busy doing a bunch of things & doesn't have time to answer you. You write on a whiteboard in a room at the party "Is there any soy sauce?" Someone at the party who's more familiar with the host writes under it "I looked & didn't see any, I don't think there's any in the house." You write under it "When someone goes to the store to get more ice can they grab some?" because you know it's such a bog party that people will be going to the store multiple times to get ice... Okay, it's not a perfect analogy, but bare with me... Someone writes back "I'll let people know, but none of us see any reason to put soy sauce on a hamburger." You reply back "I get that but there's dozens of us here looking & we keep finding others who ask if there's any soy sauce." You get a response that says "It looks like nobody here is willing to go grab it, if one of you want to grab some we'll make sure it's not going to cause anyone an allergic reaction &, if not, we'll put it out with the hamburgers" You reply "But it's not expensive, I'd be willing to buy it, but I can't drive" To which the whiteboard is wiped clean to make room for other things, but the conversation is transferred to a small notebook in the reading room because this is a really nice house or something

[jamescarppe]

A while back we moved to using discussions for questions and feature requests, keeping issues for bug reports exclusively. This is to let us gauge community feedback more easily and to facilitate wider discussion on ideas and implementation. Doing this does not change the way we approach or prioritize feature requests in any way - in fact, the new approach gives us more insight into feature requests than we had previously. Closing the old issue in favor of this discussion was in no way closing or ignoring the feature request, it was simply a reorganization of how we categorize and track feature requests.

In terms of this particular issue, you could argue both ways about whether this is a bug or a missing feature. We've decided to look at it as a missing feature, and opened an internal issue around it late last year which we are actively pursuing. It looks like we missed indicating that we'd done so here at the time, and we're sorry that this was missed. I don't have an ETA on when this might make it into the product at this stage, but rest assured we aren't ignoring it.

There was also some initial confusion around the issue as to whether it related to the logs of the Portainer container itself, or to the logs of other containers viewed through Portainer. The feature request is focused on the latter of the two.

Bear in mind also that we are a small team working on a number of features and bug fixes across a wide ranging product, so we need to prioritize our time accordingly. We have a knowledge base article which outlines our process around bug and feature prioritization.

I appreciate this might not necessarily be the answer you're looking for, but hopefully it adds a bit of clarity around where we're at with it and with our general processes.

Internal Ref: PCT-248

[taulen]

Any updates ?

[moshin34]

Hi from late 2025. This timezone nonsense is annoying. any plans to resolve?

[y525455383]

居然是一个延续这么多年的问题