My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 131: DateProperty does not work properly in dev environment
23 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  ----
Closed:  May 2008


Sign in to add a comment
 
Reported by joshuafl...@gmail.com, Apr 10, 2008
What steps will reproduce the problem?
1. Run code in dev_appserver on a machine with a negative UTC offset (ex:
CST -5)
2. Store a datetime.date value in a db.DateProperty()
3. Retrieve the entity from the data store and display the DateProperty


What is the expected output? What do you see instead?
The loaded date should be the same date that was saved.
Instead, the loaded date is the previous date.
The dev environment should simulate the production environment where the
machines are configured for UTC, so that no offset is applied to a date
when it is saved.

What version of the product are you using? On what operating system?
dev_appserver release 1.0 timestamp: 1206675800
ActiveState Python 2.5.2
WinXP SP2 in US Central time zone (-5)

Please provide any additional information below.
Run this handler in dev_appserver on a machine with a negative timezone offset:

class DateRepro(webapp.RequestHandler):
    def get(self):
        for oldHolder in ReproHolder.all():
            oldHolder.delete()
            
        holder = ReproHolder()
        holder.theDate = datetime.date(2008, 4, 10)
        self.response.out.write('saving %s ' % holder.theDate)
        holder.put()

        loadedHolder = ReproHolder.all().fetch(1)[0]
        self.response.out.write('loaded %s' % loadedHolder.theDate)
Apr 10, 2008
#1 joshuafl...@gmail.com
Forgot part of the repro code. It requires this model class:

class ReproHolder(db.Model):
    theDate = db.DateProperty()


The output from running the code is:
saving 2008-04-10 loaded 2008-04-09
Apr 10, 2008
#2 mike.t...@gmail.com
print os.environ['TZ'] returns 'UTC' on both local & production servers, but it
behaves incorrectly on local and correctly on production.
Apr 11, 2008
#3 joshuafl...@gmail.com
The issue is even more troublesome when you notice that every time you load and then
save the entity (without explicitly modifying the DateProperty), the date will
decrement. The framework is automatically doing the "to UTC" conversion every time,
but never doing the "from UTC" conversion.
Apr 11, 2008
#4 joshuafl...@gmail.com
Just realized it is also happening with DateTime properties. I have a property
declared as db.DateTimeProperty(auto_now_add=True)
I never modify it in code, but every time I load and save the entity, it decrements
the hours by 10 (applying my -5 offset twice?)
Apr 11, 2008
#5 mike.t...@gmail.com
Just in case this is a Windows-specific issue -- yes, I'm running on Windows XP, just
like Josh.
Apr 12, 2008
#6 sgra...@gmail.com
Same issue here.  It happens with DateTimeProperty, DateProperty, and TimeProperty. 
Every time I edit and subsequently save a model entity all three of these Properties
will decrement.  I've had it decrement to the point that it threw a BadValueError on
subsequent saves.
  
WinXP SP2 in EST time zone.  
Python 2.5.2. 
AppEngine release: "1.0"
timestamp: 1206675800
api_versions: ['1']
Apr 12, 2008
#7 phil.jam...@gmail.com
Same.  Thought I was going mad.  Doing a load, modifying other values of stored item
and doing a put to update, day decrements by 1 each time.
Apr 13, 2008
#8 lath...@visionary.com
I see the same behavior as well

WinXP SP2 in CST
Python 2.5.2
Apr 15, 2008
#9 ry...@google.com
Thanks for the reports, all, and sorry for the trouble. It looks like this is an
issue in the SDK that should be fixed in the next release. Until then, you can work
around it by calling time.tzset() in your app's initialization code.
Status: Accepted
Apr 15, 2008
#10 geli.cr...@gmail.com
I just wanted to add that it also happens with a positive UTC offset. I'm in UTC+2,
and the DateTime Property is incremented by 4 hours with every update of the entity.
Apr 15, 2008
#11 mike.t...@gmail.com
Is there a solution on Windows? Windows Python doesn't have time.tzset().
Apr 15, 2008
#12 sgra...@gmail.com
Agreed.  time.tzset() is not available on Windows python based on the Google searches
for it.
Apr 18, 2008
#13 mahmoud....@gmail.com
Hmm. It seems that the solution would be to change your computers timezone through
the control panel.
Apr 23, 2008
#14 EarthToG...@gmail.com
I tried a patch to module datastore_types.py, which seems to work:

change line 1033
from
    lambda val: datetime.datetime.fromtimestamp(float(val) / 1000000.0),
to
    lambda val: datetime.datetime.utcfromtimestamp(float(val) / 1000000.0),

Per the Python doc, fromtimestamp() converts to the local timezone.

Apr 24, 2008
#15 luddl...@gmail.com
Tried EarthToGary's patch and it seems to work. Thanks! This was driving me crazy for
hours.
May 6, 2008
#16 brian.wh...@gmail.com
agreed, EarthToGary's patch worked perfectly.

SO glad I wasn't the only one experiencing this problem!
May 6, 2008
#17 carmiac
As my app deals very heavily with daily records, this was driving me nuts!
And, like the above commenters, EarthToGary's patch solved all my problems.
May 9, 2008
Project Member #18 ma...@google.com
This issue has been fixed in version 1.0.2 of the SDK, please download it here:
https://code.google.com/p/googleappengine/downloads/list
Status: Fixed
Jul 9, 2008
#19 paul.marrington.net
I am not sure it has been fixed. I have a model class with a datetime object. On the
dev appengine the first time the test is run (meaning libraries loaded) it changes
the time on write by 10 hours (we are +10 here). I have traced the db code all the
way and it is the correct date, yet after the write I can look at the data store and
see one 10 hours out. Running the test repeatedly will give the correct date until
you wait for a period of time (probably 30 seconds or so). Then the first run will be
wrong and all future ones right. My test is a single file if you would like to see if
it is the same elsewhere. My platform is OS X.
record.py
2.4 KB   View   Download
Sign in to add a comment

Powered by Google Project Hosting