Not a problem! ;)
Here the *model*:
> db.define_table('news',
> Field('title', 'string'),
> Field('body', 'text'),
> Field('date_local', 'datetime'),
> Field('date_utc', 'datetime', readable=False, writable=False)
> )
>
> db.news.title.requires = [IS_NOT_EMPTY(), IS_NOT_IN_DB(db, 'news.title')]
> db.news.body.requires = IS_NOT_EMPTY()
> db.news.date_local.requires = IS_NOT_EMPTY()
>
Here the *controller*:
> @auth.requires_login()
> def insertnews():
> form = crud.create(db.news, next=URL('index'),
> onvalidation=localtime_to_utc)
> return dict(form=form)
>
Here the *view*:
> {{
=form.custom.begin
> =form.custom.widget.title
> =form.custom.widget.body
> =form.custom.widget.date_local
> =form.custom.submit
> =form.custom.end
> }}
>
And here the module to convert the local time to UTC:
> from datetime import timedelta
> def localtime_to_utc(form):
> form.vars.dateUTC = form.vars.date_local - timedelta(hours=2)
>
The error I get is:
> TypeError: unsupported operand type(s) for -: 'str' and
> 'datetime.timedelta'
>
Just tell me if I have to provide other information about the issue.
Thanks a lot. :)
Best,
David
On 11 October 2012 22:44, Massimo Di Pierro <[email protected]>wrote:
> We need to see some of the code. Somehow the validator is not called.
>
>
> On Thursday, 11 October 2012 13:32:40 UTC-5, David Sorrentino wrote:
>
>> I'm using a custom form, but no custom validators.
>> Do you need some additional information?
>>
>> Cheers,
>> David
>>
>>
>> On 11 October 2012 15:34, Massimo Di Pierro <[email protected]>wrote:
>>
>>> 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 <[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
>>>>>>> >>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>> --
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>> --
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >>
>>>>>>> > --
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>
>>>
>>>
>>>
>>
>> --
>
>
>
>
--
