Is it possible you have a custom validator?
is should have a IS_DATE validator (default). It is the validator that maps
request.vars.date into form.vars.date and performs the conversion.
On Thursday, 11 October 2012 06:30:46 UTC-5, David Sorrentino wrote:
>
> 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 <nip...@gmail.com <javascript:>> 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 <alec.t...@gmail.com> 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> 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
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>> --
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>
>>>> >>>>
>>>> >>> --
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> > --
>>>> >
>>>> >
>>>> >
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>> --
>>
>>
>>
>>
>
>
--
