Re: /etc/localtime
Web browsers are what are generating the UI - so when they generate the UI they use the client timezone (which is almost always correct) On Fri, Jul 8, 2016 at 1:14 PM, Luke Meyer wrote: > 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 > 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 < >> brandon.rich...@imail.org> 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 >>> *Date: *Friday, July 8, 2016 at 8:56 AM >>> *To: *Luke Meyer >>> *Cc: *Brandon Richins , dev < >>> dev@lists.openshift.redhat.com> >>> *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 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 < >>> brandon.rich...@imail.org> 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: * on behalf of Luke >>> Meyer >>> *Date: *Wednesday, July 6, 2016 at 11:27 AM >>> *To: *dev >>> *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 >>> dev@lists.openshift.redhat.com >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>> >>> >> > ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: /etc/localtime
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 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 < > brandon.rich...@imail.org> 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 >> *Date: *Friday, July 8, 2016 at 8:56 AM >> *To: *Luke Meyer >> *Cc: *Brandon Richins , dev < >> dev@lists.openshift.redhat.com> >> *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 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 < >> brandon.rich...@imail.org> 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: * on behalf of Luke Meyer >> >> *Date: *Wednesday, July 6, 2016 at 11:27 AM >> *To: *dev >> *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 >> dev@lists.openshift.redhat.com >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> >> > ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: /etc/localtime
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 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 > *Date: *Friday, July 8, 2016 at 8:56 AM > *To: *Luke Meyer > *Cc: *Brandon Richins , dev < > dev@lists.openshift.redhat.com> > *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 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 > 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: * on behalf of Luke Meyer < > lme...@redhat.com> > *Date: *Wednesday, July 6, 2016 at 11:27 AM > *To: *dev > *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 > dev@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > > ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: /etc/localtime
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 Date: Friday, July 8, 2016 at 8:56 AM To: Luke Meyer Cc: Brandon Richins , dev 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 mailto:lme...@redhat.com>> 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 mailto:brandon.rich...@imail.org>> 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: mailto:dev-boun...@lists.openshift.redhat.com>> on behalf of Luke Meyer mailto:lme...@redhat.com>> Date: Wednesday, July 6, 2016 at 11:27 AM To: dev mailto:dev@lists.openshift.redhat.com>> 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 dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
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 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 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: * on behalf of Luke Meyer < > lme...@redhat.com> > *Date: *Wednesday, July 6, 2016 at 11:27 AM > *To: *dev > *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 dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: /etc/localtime
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 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: * on behalf of Luke Meyer < > lme...@redhat.com> > *Date: *Wednesday, July 6, 2016 at 11:27 AM > *To: *dev > *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 dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: /etc/localtime
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: on behalf of Luke Meyer Date: Wednesday, July 6, 2016 at 11:27 AM To: dev 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 dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
/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 dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev