Skip to content
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

Alpine docker image does not obey local timezone anymore #59636

Closed
nalla opened this issue Sep 27, 2021 · 7 comments
Closed

Alpine docker image does not obey local timezone anymore #59636

nalla opened this issue Sep 27, 2021 · 7 comments

Comments

@nalla
Copy link

nalla commented Sep 27, 2021

Description

The release 6.0.0-rc.1 does not obey the local timezone information. This is a regression, see the following steps to reproduce

Steps to reproduce

private static void Main(string[] args)
{
	Console.WriteLine(TimeZoneInfo.Local.DisplayName);
}

Working

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
    WORKDIR /build
    COPY src/Foo.sln .
    COPY src/Foo/*.csproj ./Foo/
    RUN dotnet restore ./Foo.sln
    COPY src/Foo/ ./Foo/
FROM build as publish
    WORKDIR /build/Foo
    RUN dotnet publish -c Release -o out
FROM mcr.microsoft.com/dotnet/aspnet:5.0-alpine AS runtime
    RUN apk update --no-cache && apk upgrade --no-cache
    RUN apk add --no-cache tzdata
    ENV TZ=Europe/Berlin
    ENV LANG=de_DE.UTF-8
    ENV LANGUAGE=${LANG}
    ENV LC_ALL=${LANG}
    RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
    WORKDIR /app
    COPY --from=publish /build/Foo/out ./
    ENTRYPOINT [ "dotnet", "Foo.dll" ]

This will produce the following output

(UTC+01:00) CET

Bug

When you now take the same code, change target framework from net5.0 to net6.0 and use the same Dockerfile as a base and use mcr.microsoft.com/dotnet/sdk:6.0 and mcr.microsoft.com/dotnet/aspnet:6.0-alpine, you will get the following output

(UTC+00:00) Coordinated Universal Time
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Sep 27, 2021
@am11
Copy link
Member

am11 commented Sep 27, 2021

Seems like TZ was working as expected on .NET 5 with DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true (preset environment variable in alpine runtime container), but not on .NET 6.

- FROM mcr.microsoft.com/dotnet/aspnet:5.0-alpine AS runtime
+ FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine AS runtime
    RUN apk update --no-cache && apk upgrade --no-cache
-   RUN apk add --no-cache tzdata
+   RUN apk add --no-cache tzdata icu-libs
    ENV TZ=Europe/Berlin
    ENV LANG=de_DE.UTF-8
    ENV LANGUAGE=${LANG}
    ENV LC_ALL=${LANG}
+   ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false
    RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
    WORKDIR /app
    COPY --from=publish /build/Foo/out ./
    ENTRYPOINT [ "dotnet", "Foo.dll" ]

results in:

Console.WriteLine(TimeZoneInfo.Local.DisplayName)
// (UTC+01:00) Mitteleuropäische Zeit (Berlin)

Console.WriteLine(TimeZoneInfo.Local.Id)
// (Berlin) Europe/Berlin

on both, 5.0 and 6.0.

not sure if it is an intentional change or accidental breakage.

@nalla
Copy link
Author

nalla commented Sep 27, 2021

Thanks, this works. So current behavior is correct, net5.0 behavior was somewhat faulty?

@nalla nalla closed this as completed Sep 27, 2021
@am11
Copy link
Member

am11 commented Sep 27, 2021

Perhaps @GrabYourPitchforks and @tarekgh can answer more accurately whether or not if it is a regression. To me the behavior of net5.0 seems correct; recognize correct TZ even in the invariant mode.

@tarekgh tarekgh reopened this Sep 28, 2021
@tarekgh tarekgh added area-System.Runtime and removed untriaged New issue has not been triaged by the area owner labels Sep 28, 2021
@ghost
Copy link

ghost commented Sep 28, 2021

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

The release 6.0.0-rc.1 does not obey the local timezone information. This is a regression, see the following steps to reproduce

Steps to reproduce

private static void Main(string[] args)
{
	Console.WriteLine(TimeZoneInfo.Local.DisplayName);
}

Working

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
    WORKDIR /build
    COPY src/Foo.sln .
    COPY src/Foo/*.csproj ./Foo/
    RUN dotnet restore ./Foo.sln
    COPY src/Foo/ ./Foo/
FROM build as publish
    WORKDIR /build/Foo
    RUN dotnet publish -c Release -o out
FROM mcr.microsoft.com/dotnet/aspnet:5.0-alpine AS runtime
    RUN apk update --no-cache && apk upgrade --no-cache
    RUN apk add --no-cache tzdata
    ENV TZ=Europe/Berlin
    ENV LANG=de_DE.UTF-8
    ENV LANGUAGE=${LANG}
    ENV LC_ALL=${LANG}
    RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
    WORKDIR /app
    COPY --from=publish /build/Foo/out ./
    ENTRYPOINT [ "dotnet", "Foo.dll" ]

This will produce the following output

(UTC+01:00) CET

Bug

When you now take the same code, change target framework from net5.0 to net6.0 and use the same Dockerfile as a base and use mcr.microsoft.com/dotnet/sdk:6.0 and mcr.microsoft.com/dotnet/aspnet:6.0-alpine, you will get the following output

(UTC+00:00) Coordinated Universal Time
Author: nalla
Assignees: -
Labels:

area-System.Runtime

Milestone: -

@tarekgh tarekgh added this to the 6.0.0 milestone Sep 28, 2021
@tarekgh
Copy link
Member

tarekgh commented Sep 28, 2021

Thanks @nalla for reporting this issue. It is a regression and I am looking at it.

@tarekgh tarekgh self-assigned this Sep 28, 2021
@ghost ghost added in-pr There is an active PR which will close this issue when it is merged and removed in-pr There is an active PR which will close this issue when it is merged labels Sep 28, 2021
@tarekgh
Copy link
Member

tarekgh commented Sep 29, 2021

This issue is addressed by the PR #59727.

@tarekgh tarekgh closed this as completed Sep 29, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Nov 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants