Changed the name of the field from "date" to "created_on" to avoid confusion. Tried with a fresh table. Result: *form.vars.created_on* seems to be still an object of type str.
Am I missing something? :-/ Cheers, David On 11 October 2012 11:45, Niphlod <[email protected]> wrote: > uhm. I can't reproduce the issue. For me form.vars.whatever if is a field > of type datetime is a datetime tuple. Request.vars.whatever on the other > hand is always a string, as it should be. > > Try with a fresh table > > PS: having a db with a column named "date" is a call for problems ... > > On Thursday, October 11, 2012 11:27:52 AM UTC+2, David Sorrentino wrote: > >> Thanks for your explanation Niphlod. ;) >> >> I'm trying to normalize the time, as you suggested. >> However I'm facing some difficulties. >> >> In particular I created an additional field in my table to store the >> normalized time (UTC) too. So now my table looks like that: >> >>> db.define_table('news', >>> Field('title', 'string'), >>> Field('body', 'text'), >>> Field('date', 'datetime'), >>> Field('dateUTC', 'datetime', readable=False, writable=False) >>> ) >>> >> >> I decided to compute the field "dateUTC" onvalidation. My controller >> looks like that: >> >>> def insertnews(): >>> form = crud.create(db.news, next=URL('index'), >>> onvalidation=localtime_to_utc) >>> return dict(form=form) >>> >> >> Eventually, assuming that I want to normalize the local time of Rome (+2 >> hours) the function I use to do that looks so: >> >>> def localtime_to_utc(form): >>> form.vars.dateUTC = form.vars.date - timedelta(hours=2) >>> >> >> The problem is that *form.vars.date* seems to be a string. O_O >> Indeed I get this error: >> >>> TypeError: unsupported operand type(s) for -: 'str' and >>> 'datetime.timedelta' >>> >> >> Now I wonder, is it normal that a form.vars is considered a string? Is >> there any way to retrieve the original type (datetime), in order to compute >> the normalization? >> >> @Alec: if I manage I'll send them a mail with the solution! ;) >> >> Cheers, >> David >> >> >> On 10 October 2012 14:35, Alec Taylor <[email protected]> wrote: >> >>> Also if it makes you feel better LinkedIn hasn't implemented this >>> properly either :P >>> >>> On Wed, Oct 10, 2012 at 10:57 PM, Niphlod <[email protected]> wrote: >>> > welcome to datetime madness :D It's exactly what you need to take into >>> > consideration if you're working with user-inputted datetimes. You'd >>> need to >>> > retrieve it's local date (javascript comes to the rescue, or based on >>> > nation, or whatever) and calculate the difference between that and your >>> > current date, then subtract/add the difference to the actually >>> submitted >>> > datetime to "normalize" it in a UTC form. >>> > >>> > >>> > On Wednesday, October 10, 2012 1:01:35 PM UTC+2, David Sorrentino >>> wrote: >>> >> >>> >> I see your point, but what if the user inserts into the datetime input >>> >> field his/her current time? It will be different from the server's one >>> >> (which I set to GMT), and prettydate will not work properly. >>> >> >>> >> I confess that I am a bit confused about that. >>> >> >>> >> Best, >>> >> David >>> >> >>> >> >>> >> On 10 October 2012 11:16, Niphlod <[email protected]> wrote: >>> >>> >>> >>> not necessarily wrong, just a different timezone. If you're going to >>> >>> display "prettydates" just in the browser for a "nicer >>> visualization" you >>> >>> should take into consideration that your server's locatime can be >>> different >>> >>> from the users's browser one. >>> >>> >>> >>> In a "perfect" setup, your server is on GMT (that is, utc), your app >>> uses >>> >>> request.utcnow in all the places instead of request.now (and >>> >>> datetime.datetime.utcnow() instead of datetime.datetime.utcnow()). >>> You'll >>> >>> have prettydate working right. >>> >>> >>> >>> >>> >>> On Wednesday, October 10, 2012 10:38:32 AM UTC+2, David Sorrentino >>> wrote: >>> >>>> >>> >>>> Hey Niphlod, >>> >>>> >>> >>>> Thank you for your help. >>> >>>> >>> >>>> The version is 2.0.9 (2012-10-05 09:01:45) dev >>> >>>> >>> >>>> I tried datetime.datetime.now() in my application and I just >>> discovered >>> >>>> that it is 2 hours late. This explains why prettydate is then 2 >>> hours in >>> >>>> hurry! >>> >>>> The odd thing is that if I open a python console and try >>> >>>> datetime.datetime.now(), I get the right time. O_O >>> >>>> >>> >>>> Something wrong with my server? >>> >>>> >>> >>>> Cheers, >>> >>>> David >>> >>>> >>> >>>> >>> >>>> On 10 October 2012 10:28, Niphlod <[email protected]> wrote: >>> >>>>> >>> >>>>> should calculate the difference between datetime.datetime.now() and >>> >>>>> your date. what web2py version are you using ? >>> >>>>> >>> >>>>> >>> >>>>> On Wednesday, October 10, 2012 10:16:24 AM UTC+2, David Sorrentino >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Hello everybody, >>> >>>>>> >>> >>>>>> I am using the module prettydate, but it seems that it matches the >>> >>>>>> datetime I give as input with a wrong timezone. >>> >>>>>> >>> >>>>>> For example now it's 10:12 am at my place. >>> >>>>>> >>> >>>>>> This is the datetime I give as input: 2012-10-10 10:12:00. >>> >>>>>> >>> >>>>>> This is the code: >>> >>>>>> >>> >>>>>>> from gluon.tools import prettydate >>> >>>>>>> pretty_d = prettydate(input_datetime, T) >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> And this is the result: "2 hours from now". >>> >>>>>> It's 2 hours in hurry!! :) >>> >>>>>> >>> >>>>>> Am I wrong in something? >>> >>>>>> >>> >>>>>> I wish you a wonderful Wednesday, >>> >>>>>> David >>> >>>>>> >>> >>>>>> >>> >>>>> -- >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>> >>> >>>> >>> >>> -- >>> >>> >>> >>> >>> >>> >>> >> >>> >> >>> > -- >>> > >>> > >>> > >>> >>> -- >>> >>> >>> >>> >> -- > > > > --
