Repository navigation
time: Docker image passes the literal ${LOCAL_TIMEZONE} to --local-timezone #5182
Description
Problem
The mcp/time Docker image passes the literal string ${LOCAL_TIMEZONE} to the server as its --local-timezone argument. src/time/Dockerfile ends with an exec-form entrypoint:
ENV LOCAL_TIMEZONE=${LOCAL_TIMEZONE:-"UTC"}
ENTRYPOINT ["mcp-server-time", "--local-timezone", "${LOCAL_TIMEZONE}"]Docker performs no variable substitution in the exec (JSON array) form of ENTRYPOINT, so the process receives ${LOCAL_TIMEZONE} verbatim rather than UTC or the value set with docker run -e LOCAL_TIMEZONE=…. The ENV line's shell-style default is also only expanded against build-time values, not a runtime -e.
Expected
The container uses LOCAL_TIMEZONE from the environment at run time, defaulting to UTC when unset.
Notes
Found by static reading of the Dockerfile during the backlog triage (#4876); nothing in CI builds the Docker images (see #4782), which is how it went unnoticed. A fix would read the variable at run time, for example a shell-form entrypoint or having the server fall back to the LOCAL_TIMEZONE environment variable.
Activity
cliffhall commentedon Oct 19, 2026
Triage: Priority Medium (total 7)
${LOCAL_TIMEZONE}, so the timezone option is unusable in the container; running the package directly is the workaroundbuglabelBoard: Servers V2 (#43), Status
Incoming, awaiting maintainer review (no milestone yet). Part of the backlog triage in #4875.cliffhall commentedon Oct 20, 2026
Prior work, from the PR backlog triage (#4877). These outside pull requests addressed this issue against the pre-refactor code:
They are being closed as part of the backlog triage in #4875, since the repository now takes issues rather than outside PRs and their diffs predate the v2 refactor. They stay readable and serve as prototypes for the fix here. Thank you to their authors.