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 <alec.t...@gmail.com
> <javascript:>>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 <nip...@gmail.com <javascript:>>
>> 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 <nip...@gmail.com> 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 <nip...@gmail.com> 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
>> >>>>>>
>> >>>>>>
>> >>>>> --
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>> --
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> > --
>> >
>> >
>> >
>>
>> --
>>
>>
>>
>>
>
--
