UI should be using the client's local timezone, so that's not really a
problem.  No server should ever be translating output to its local timezone.

On Fri, Jul 8, 2016 at 11:27 AM, Brandon Richins <[email protected]>
wrote:

> I agree about the UI for the caller.  However, in some circumstances, 99%
> of the business use cases and customers are in the same timezone as the
> servers running the apps.  if the UI is generated on a server, like old
> servlet JEE tech, then having the app timezone set (regardless of client
> timezone) may be useful.  I can also see a case for scheduled/cron-like
> jobs being more readable with an assumed timezone.
>
>
>
> *Brandon Richins*
>
>
>
> *From: *Clayton Coleman <[email protected]>
> *Date: *Friday, July 8, 2016 at 8:56 AM
> *To: *Luke Meyer <[email protected]>
> *Cc: *Brandon Richins <[email protected]>, dev <
> [email protected]>
> *Subject: *Re: /etc/localtime
>
>
>
> Shouldn't logs be written to UTC and the UI of the caller be used for that?
>
>
>
> I would expect all the stored data to be normalized correctly when shown.
>
>
> On Jul 8, 2016, at 10:49 AM, Luke Meyer <[email protected]> wrote:
>
> If you can docker run as shown, sure, you can mount in the appropriate
> thing for your container distro, or set an env var. I'm looking for a more
> generic addition to the OpenShift Origin container environment. When you
> "oc new-app" a template you don't know what timezone the resulting node
> will have, and you don't particularly want to require the hostmount SCC
> just for that. Since the distro in the container could be looking at
> different files, I thought it would be a good to have kubernetes add the
> timezone into a known env var. The container doesn't necessarily have to
> use it but that way it could choose e.g. to write logs with a timezone that
> matches the host, or to offer a good UI default for the administrator's
> timezone.
>
>
>
> On Wed, Jul 6, 2016 at 2:40 PM, Brandon Richins <[email protected]>
> wrote:
>
> It looks like this could be a complicated issue.  I searched around a
> little because a colleague of mine had some timezone issues with Docker
> lately.  I think each distro may have its own way of doing timezones.  Many
> seem to share the /etc/timezone, /etc/localtime, and /usr/share/zoneinfo
> files/folders.  Alpine doesn’t seem to come with timezone data in their
> base image.
>
>
>
> It appears to me that the kernel keeps time in UTC and therefore Docker
> (by default) will use UTC for its containers.  I’ve seen posts to either
> export the TZ environment variable or to use host mounts.
>
>
>
>
> http://olavgg.com/post/117506310248/docker-how-to-fix-date-and-timezone-issues
>
> sudo docker run --rm -it \
>
>   -v /etc/localtime:/etc/localtime:ro \
>
>   -v /etc/timezone:/etc/timezone:ro \
>
>   --name my_container debian:jessie date
>
>
>
> Please correct me if I’m wrong.
>
>
>
> *Brandon Richins*
>
>
>
> *From: *<[email protected]> on behalf of Luke Meyer <
> [email protected]>
> *Date: *Wednesday, July 6, 2016 at 11:27 AM
> *To: *dev <[email protected]>
> *Subject: */etc/localtime
>
>
>
> Is there a simple way to find out the host's local timezone without having
> to mount /etc/localtime (which is pretty painful given it requires
> hostmount)? Could there be some way it's passed in as an env var or
> something?
>
>
>
> _______________________________________________
> dev mailing list
> [email protected]
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
_______________________________________________
dev mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to