Hey Folks, Here's the PIT thread to track this <https://code.google.com/p/googleappengine/issues/detail?id=12840&thanks=12840&ts=1458248968>. Expect any updates to be posted there.
On Thursday, March 17, 2016 at 4:40:45 PM UTC-4, Jon Parrott wrote: > > To further Nick's point here, Python provides datetime.datetime.utcnow() > which allows you to explicitly get the current time in UTC. It's almost > always preferable to use that unless you explicitly want to deal with > system-local time. > > On Wednesday, March 16, 2016 at 12:30:33 PM UTC-7, Nick (Cloud Platform > Support) wrote: >> >> Hey Michael, >> >> We're currently working on getting this resolved, although the best way >> to track its resolution is by posting and following a Public Issue Tracker >> issue. At any rate, we're currently working on it and it should be resolved >> soon. If your application is sensitive to the system time-zone, the natural >> recourse is to set it explicitly, rather than assume a default. >> Nonetheless, UTC is a sensible default I believe and should be implemented. >> >> I'll update this thread with any progress on the issue. >> >> Best wishes, >> >> Nick >> Cloud Platform Community Support >> >> On Wednesday, March 16, 2016 at 2:01:46 PM UTC-4, Michael Sander wrote: >>> >>> I've seen this too, but I just started working on Managed VM. Has this >>> been around for a while? It seems like a pretty major bug for it not to be >>> fixed. Also, the workaround is totally nuts. Is this going to be fixed or >>> is the hack our only recourse? >>> >>> On Thursday, March 10, 2016 at 6:54:04 PM UTC-5, Nick (Cloud Platform >>> Support) wrote: >>>> >>>> Hey Adam, >>>> >>>> Glad to see you found a workaround, I was going to some lengths to >>>> verbally describe what you basically ended up doing. You should post a >>>> quick description of this issue to the Public Issue Tracker for App >>>> Engine <https://code.google.com/p/googleappengine/issues/list> and >>>> we'll be happy to take a look. It seems rational to have UTC as the >>>> default. >>>> >>>> Cheers, >>>> >>>> Nick >>>> Cloud Platform Community Support >>>> >>>> On Thursday, March 10, 2016 at 6:28:39 PM UTC-5, Adam Sah wrote: >>>>> >>>>> OK, horrible workaround deployed. Roughly: >>>>> >>>>> main.py: >>>>> >>>>> PATHS=[... >>>>> (r'/_ah/warmup', WarmupView), >>>>> (r'/_ah/start', StartView), >>>>> >>>>> class WarmupView(webapp.RequestHandler): >>>>> def get(self, *args): # pylint:disable=W0613,R0201 >>>>> base.SERVER_TZ = None # allow base.set_now() to reset server >>>>> timezone >>>>> base.now() >>>>> >>>>> class StartView(webapp.RequestHandler): >>>>> def get(self, *args): # pylint:disable=W0613,R0201 >>>>> base.SERVER_TZ = None # allow base.set_now() to reset server >>>>> timezone >>>>> base.now() >>>>> >>>>> base.py: >>>>> >>>>> import pytz >>>>> ... >>>>> SERVER_TZ = None >>>>> ... >>>>> def now(nowval=None): >>>>> global SERVER_TZ >>>>> ... >>>>> if SERVER_TZ is None: >>>>> try: >>>>> # HACK of the year award! os.environ['TZ'] isn't available >>>>> during GAE/Managed VMs startup >>>>> # and date +%Z and /etc/timezone didn't have useful >>>>> information either >>>>> # even env | grep TZ failed!! >>>>> import subprocess >>>>> localtz = subprocess.check_output("date +%Z", >>>>> shell=True).strip() >>>>> # SUPER HACK: I couldn't find pytz-compatible timezone >>>>> strings, so I hacked it. >>>>> # Yes, I know I'm going to hell for this. >>>>> SERVER_TZ = 'America/Chicago' if localtz == 'CST' else 'UTC' >>>>> except: >>>>> SERVER_TZ = 'UTC' >>>>> nowval = datetime.datetime.now() # pylint:disable=W9914 >>>>> if SERVER_TZ != 'UTC': >>>>> # set the tz to the server tz, convert to UTC, then strip the tz >>>>> info >>>>> nowval = >>>>> nowval.replace(tzinfo=pytz.timezone(SERVER_TZ)).astimezone( >>>>> pytz.timezone('UTC')).replace(tzinfo=None) >>>>> return nowval >>>>> >>>>> >>>>> adam >>>>> >>>>> >>>>> On Thursday, March 10, 2016 at 1:01:57 PM UTC-8, Adam Sah wrote: >>>>>> >>>>>> oops, to be specific here's what I'm seeing: >>>>>> >>>>>> datetime.datetime.now().strftime("%c %Z") ==> Thu Mar 10 14:57:31 >>>>>> 2016 (i.e. timestamp is in CST with no timezone info) >>>>>> os.environ['TZ'] ==> America/Chicago >>>>>> >>>>>> where dev_appserver and standard GAE return: >>>>>> >>>>>> datetime.datetime.now().strftime("%c %Z") ==> Thu Mar 10 21:00:14 >>>>>> 2016 (i.e. timestamp is in UTC with no timezone info) >>>>>> os.environ['TZ'] ==> 'UTC' >>>>>> >>>>>> adam >>>>>> >>>>>> On Thursday, March 10, 2016 at 12:32:07 PM UTC-8, Adam Sah wrote: >>>>>>> >>>>>>> Here's what I've tried so far... >>>>>>> - set os.environ['TZ'] to 'UTC' on startup - failed because GAE >>>>>>> overwrites this. >>>>>>> - set os.environ['TZ'] to 'UTC' on each call by creating a child >>>>>>> class to webapp.WSGIApplication and adding it to __call__() - failed >>>>>>> because GAE overwrites this. >>>>>>> - monkeypatching datetime.datetime.now() to use a specially hacked >>>>>>> function - failed because GAE disallows modifying now() >>>>>>> >>>>>>> I'm currently trying a hack to rewrite all calls (100+) >>>>>>> to datetime.datetime.now() to instead use an app-specific >>>>>>> implementation >>>>>>> which returns the UTC time - this won't work for third party libraries, >>>>>>> but >>>>>>> that maybe OK for my app, which uses pylint custom rules to migrate >>>>>>> engineers to using app-specific replacement functions (e.g. we disallow >>>>>>> direct calls to gc.collect() so we can track stats better). If this >>>>>>> works, >>>>>>> I'll post. >>>>>>> >>>>>>> adam >>>>>>> >>>>>>> >>>>>>> On Wednesday, March 9, 2016 at 1:45:54 PM UTC-8, Adam Sah wrote: >>>>>>>> >>>>>>>> e.g. os.environ['TZ'] changed to America/Chicago when before it was >>>>>>>> UTC. >>>>>>>> >>>>>>>> The docs don't mention this difference anywhere. >>>>>>>> >>>>>>>> If anyone has a workaround, pls reply - I'm working on a workaround >>>>>>>> now, will post if successful. >>>>>>>> >>>>>>>> hope this helps, >>>>>>>> adam >>>>>>>> >>>>>>>> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/026ecfc1-8f0c-4647-bc2c-5cd3d0dcb522%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.