That would be nice, if clients reported their timezone. Web browsers don't, leaving you with UI hacks to try to determine it, or the more standard method of having the user specify it.
Docker json files report each line's timestamp in UTC I believe, however there's no guarantee what the servers inside will do regarding timezone, and there's a lot more than just logs to consider... as mentioned, scheduled/cron-type jobs are actually what inspired this question. You don't know that the user's timezone will match the server, but it's a good default guess. On Fri, Jul 8, 2016 at 12:10 PM, Clayton Coleman <[email protected]> wrote: > 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
