Re: How to edit dexterity types without needing to know about their behaviors

On Fri, 2014-03-14 at 11:32 +0100, Andreas Jung wrote:
> Johannes Raggam wrote:
> > On Fri, 2014-03-14 at 11:25 +0100, Johannes Raggam wrote:
> >> On Fri, 2014-03-14 at 02:46 -0700, ajung wrote:
> >>> ajung wrote
> >>>> johannes raggam wrote
> >>>>> i'll fix that, probably at the wine and beer sprint. but then
> >>>>> you'll still always get UTC datetime values instead of
> >>>>> localized ones, if you get the start/end attributes directly
> >>>>> from the context.
> >>>>> 
> >>>>>> Consistency-is-king Andreas
> >>>>> pragmatism is okay. johannes
> >>> Here are the facts why plone.app.event currently freaks me out.
> >>> 
> >>> The source 'start' object is v = DateTime('2008/09/09 09:00:00
> >>> GMT+2') which translates to 07:00 UTC.
> >>> 
> >>> The migration code tries to concert the DateTime instance to a
> >>> Python datetime instance with UTC timezone and setting the
> >>> 'timezone' of the event object to 'Etc/GMT+2' using
> >>> 
> >>> v = v.asdatetime() tz = str(v.tzinfo) if tz.startswith('GMT'): tz
> >>> = 'Etc/%s' % tz new_obj.timezone = tz acc =
> >>> IEventAccessor(new_obj) v =
> >>> v.replace(tzinfo=pytz.timezone('UTC')) setattr(acc, k, v)
> >> first, are you sure, that you want to use Etc/GMT+2 as timezone?
> >> Etc/GMT is not GMT, see the answer here: 
> >> http://answers.yahoo.com/question/index?qid=20090707145844AANnghH
> >> 
> >>>>> import pytz from datetime import datetime vie =
> >>>>> pytz.timezone('Europe/Vienna') etc =
> >>>>> pytz.timezone('Etc/GMT+2') dt = vie.localize(datetime.now()) 
> >>>>> dt
> >> datetime.datetime(2014, 3, 14, 11, 13, 11, 629280,
> >> tzinfo=<DstTzInfo 'Europe/Vienna' CET+1:00:00 STD>)
> >>>>> dt.astimezone(etc)
> >> datetime.datetime(2014, 3, 14, 8, 13, 11, 629280,
> >> tzinfo=<StaticTzInfo 'Etc/GMT+2'>)
> >> 
> >> then, just set the timezone on the accessor and start and end
> >> datetime as floating datetimes. if you don't have multiple timezone
> >> in the portal you are migrating, that shouldn't be a problem.
> > 
> > ... and make sure the ObjectModifiedEvent is fired, so that the 
> > data_postprocessing event handler is executed.
> 
> This is yet another reason why the implementation is _broken_ - I wonder
> how one can design and implement such a simple functionality this way.
> This is just scary.

it's not simple. first, timezones are complicated. second, timezone
conversion in form processing, where not all information is present at
any time is complicated too. just see the archetypes implementation,
where no behavior adaptering is necessary. it's complicated there too.

seriously, even if you don't want to hear it: show me a better way to do
it. i didn't find one (except for the behavior adapter stuff, recently,
which might make the behavior adaptering obsolete).
i believe that software can get better, if more people discuss it.

but first, get YOUR timezones right.



> 
> -aj
> 
> 

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
plone framework  team  member
mail: office-//[email protected]
web:  http://programmatic.pro
      http://bluedynamics.com

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEABECAAYFAlMi31kACgkQW4mNMQxDgAcMuwCgp/idYLpo0qXnpj8wfvlz1uf9
1jcAoKO5YXICi6acY38HsNUlc+cnUFqa
=+LX9
-----END PGP SIGNATURE-----