PS: current implementation breaks.... a few "self" in front of "timezone"
required ...
Anyway, I'll give it a shot generalizing how I envisioned a timezone
preference.
PS: Pytz is required
On Monday, March 18, 2013 10:12:30 AM UTC+1, Niphlod wrote:
>
> Whoops, forgot to tell that jstz is ~5kb if minified, so shipping it
> shouldn't be a problem.... at this point, preparing a new field in
> auth_user or at least a validator with the list of timezones
> ('europe/rome', 'america/denver", etc etc) to let the "client" choose it's
> own (resorting to auto-detect of course in case the user didn't set his
> preference) would be the best thing for newbies developers approaching
> timezones for the first time (there's a lot of things to grasp to handle
> them correctly).
>
> On Monday, March 18, 2013 10:03:56 AM UTC+1, Niphlod wrote:
>>
>> uhm. The real problem of a client-side implementation is that if the
>> client pc is not set correctly, it obviously fails.
>> Assuming that we're ok with that (i.e. most of the times the client clock
>> is set correctly) this implementation is fine "for the current day" but
>> doesn't account for DST at all, i.e. there are several corner-cases (read:
>> too many to count them as "acceptable exceptions") where given an offset
>> you can't tell what "zone" the client is in, so you can't recalculate
>> either the proper DST --> you end up with wrong data.
>>
>> This is a full implementation that is fine in the 99% of the cases.
>> http://pellepim.bitbucket.org/jstz/
>>
>> PS: I didn't read the implementation yet but we should "enforce" a good
>> behaviour of storing all informations as UTC and representing it as the
>> local timezone of the user, either server-side or client-side.
>>
>> PS2: Instead of reinventing the wheel, we could use moment.js and
>> https://github.com/timrwood/moment-timezone
>>
>> On Monday, March 18, 2013 3:31:24 AM UTC+1, Massimo Di Pierro wrote:
>>>
>>> I was looking at code to detect the user timezone and store dates
>>> consistently in UTC format.
>>> I made some changes in trunk to handle this. I could use some help
>>> testing.
>>>
>>> 1) In the header of your layout.html add:
>>>
>>> {{if not session.timezone:}}
>>> <script>
>>>
>>> jQuery(function(){jQuery.post('{{=URL('default','set_timezone')}}',{timezone:(new
>>>
>>> Date()).getTimezoneOffset()});});
>>> </script>
>>> {{pass}}
>>>
>>> 2) in the default controller:
>>>
>>> def set_timezone():
>>> session.timezone = int(request.vars.timezone)/60
>>>
>>> 3) Use the new timezone attribute of validators in trunk:
>>>
>>> Field('birthday','datetime',requires =
>>> IS_DATETIME(timezone=session.timezone)
>>>
>>> Does it work for you? Suggestions for improvement?
>>>
>>> Massimo
>>>
>>
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
