Your change
http://code.google.com/p/web2py/source/detail?r=37b316948f4ae0cfa8a3d566f17eb00ddca9b5c5
worked.

thanks for the fast turn-around.

Wondering aloud... would it be a good idea to add 'timestamp' as a
formal Web2py Field type? the missing microseconds of datetime on
*some* platforms is going to trip developers up.





On Sep 20, 2:35 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Can you please try trunk?
>
> On Sep 20, 8:09 am, Carl <carl.ro...@gmail.com> wrote:
>
>
>
> > It took a bit of binary upgrading to pin down this issue but I#ve
> > found that it's between 1.84.4 and 1.85.1
>
> > However since 1.85.1 (thru to 1.85.3) selects and inserts to the
> > datastore fail when I use a SQLCustom definition (see details below).
>
> > On dev_appserver all continues to work fine.
> > But locally on sqlite...  operations on the datastore fail at gluon/
> > sql.py (in v1.85.1 it's line 3323) class Set, parse() after line "elif
> > field_type == 'datetime'\"
> > (y, m, d) = [int(x) for x in str(value)[:10].strip().split('-')]
> > ValueError: need more than 1 value to unpack
>
> > Background:
> > Locally Web2py drops the microseconds from datetime. On GAE it does
> > not.
> > I need the accuracy so I added the following db.py to define a
> > Fieldtype 'timestamp':
>
> > if request.env.web2py_runtime_gae:
> >     from gluon.contrib.gql import *
> >     db = DAL('gae')
> >     session.connect(request, response, db=db)
> >     timestamp = 'datetime'
> > else: # else use a normal relational database
> >     db = DAL('sqlite://storage.sqlite')
> >     from gluon.sql import SQLCustomType
> >     import datetime
> >     from time import mktime, localtime
> >     timestamp = SQLCustomType(type='datetime',
> >                               native='NUMERIC(16,6)',
> >                               encoder=(lambda x:
> > str(mktime(x.timetuple()) + x.microsecond/1000000.0)),
> >                               decoder=(lambda x: datetime.datetime(*
> > (list(localtime(int(x))[:6])+[int(round(x%1,6)*1000000)]) )))
>
> > Is this definition of timestamp using SQLCustomType no longer
> > appropriate/workable?
> > Tables that don't include a timestamp field work correct in 1.84.x and
> > 1.85.x

Reply via email to