Not sure, if the scope is right for a GSOC project. If there is a general interest, we/I should better outline the necessary tasks and estimate the workload.
In the linked issue you stated:
""
we stored start/end times as UTC values. but that's less flexible (e.g. start and end had to be in the same timezone)
""
what's the use case for that ? The fist idea that come to mind is of a Plone conference abord a transatlantic luxury liner, but what else ?
Yes, something like that - why not
Another common one: making a journey over several timezones or simply doing a flight from Europe to Japan.
However - the timezone info is an integral data to describe a date/time and Python datetime and pytz give us everything to handle and compare timezones - no need to store the timezone info separately.
A journey don't quite make a great subject for an news item, in fact. A blog may be a better place for this kind of event.
I did a quick test (on demo.plone.de) for what is I think a less unlikely use case for news with timezone: a web conference.
So I imagined that I was at London (since the default demo.plone.de is curiously set at UTC while Germany is UTC+1) and did as Editor an announce of a webconference at 11h AM. I imagined that the Editor In Chief would be required to participate and could be located at San Francisco. The hour displayed in the Plone event was, well, 11h AM UTC. Not much help for the unfortunate Editor In Chief who would have first to lookup the world hours on the web to shout out at the british colleague that this hour was really early at Frisco.
Then I tried to do the reverse; the San Francisco Editor-In-Chief would announce a web conference. Well, that's worse. No way to use the Frisco time without changing the server time zone (!). No way to change the server time zone to San Francisco: this small and unsignificant town is not known in the official Plone list, not even California (and California would be wrong since there is 2 different times zones for this State)
Well, no matter. I'd try to imagine another scenario. The computer services would be located at Auckland (New Zealand), because Auckland is in the official Plone list. The business would have also administrative offices at San Francisco and London. The collaborator announcing a web conference would be at San Francisco and the people needing to attend at London. So I changed the demo.plone.de server timezone to Auckland; worked a treat. The event that I created at 14h (nothing indicated that it was not San Francisco hour mind...) was created and was duly announced at 14h Auckland time. Not really much help in this case too.
That's while I understand that python time is nice I wonder that there is so much to win compared to the amount of real work necessary and potential breakages to implement this switch. From the depths of Internet history I get that Plone 5 was announced in september 2015 so to Plone 5.1 there will be about 2,5 years. If a proper solution is for Plone 5.2, can Plone afford to keep its flagship version in its current state with timezones for another 2 years ?
I'm not familiar with how Plone handles datetimes, but I think that they should be stored as UTC with +0:00 (UTC) timezone, and presented to the user with their preferred timezone else a default site timezone setting.
Does Plone do that now?
Would this proposal change that?
Doing date math on UTC datetimes is less painful than on local times across timezones.
There was a nice summary of datetime issues and how to handle them at PyCon 2017.
@gp54321 I updated my initial post regarding UI issues. Currently there is no possibility to change the timezone for an event individually (in plone.app.event 1.x there was - but now that we store the timezone as part of the datetime object for start and end separately, we just didn't add the UI for that). Also - AFAIK - the user's default timezone setting isn't respected and broken. Last, we have a portal wide "available timezones" setting, which doesn't make much sense anymore (main reason for that was to limit the list of select-items in the timezone selection for the event form. But now we can just dynamically load based on user input and segment the results...). Also we do not use/guess the timezone the visitor/editor is in.
So - there are a number of UI issues which have to be resolved - that should definitely be part of this potential GSOC topic.
@stevepiercy datetime math is just painful if you have to do it yourself. But in this case Python does that for us, we do not have to worry about that. Python of course handles datetime math absolutely correctly also among different timezones. We did store dates as UTC datetimes and the timezone separately in plone.app.event 1.x but changed that for 2.x. That way the datamodel is much more flexible and also we could just drop data postprocessing after form submission (converting from the users timezone to UTC) and provide a cleaner API (developers just store the datetime with correct timezone information instead of having to remember to convert to UTC and store timezone separately). We won't change that.
The task of getting rid of Zope DateTime is mostly a cleanup task and helps for a cleaner API and much better developer experience. Zope DateTime works fine and also haves some nice convenience methods. But it's just not necessary anymore (it comes from a time where Python datetime wasn't available or at least broken) and it's a PITA to have to deal with Python datetimes and Zope DateTimes all the time.
that's all very fine the only problem I see as I was saying and you did not answer to that is that a new Plone version will need at least 2 years and really a problem like
should be fixed in 2 negative years....
My feeling is that your post was possibly motivated by the fact that I used a DateTime function to try to work around the OP poster. However there could be a way to change templates in a way that could not pose any problem when your python time change will be ready
plone_daemon@ploneprod2:/usr/local/plone-5.1-latest/ploneprod$ bin/client_reserved debug
Starting debugger (the name "app" is bound to the top-level Zope object)
>>> plone=app.Plone
>>> from zope.component.hooks import setSite
>>> setSite(plone)
>>> from plone import api
>>> with api.env.adopt_user(username="admin"):
... documents = api.content.find(context=plone)
...
>>> obj=documents[1].getObject()
>>> obj.id
'doc2test'
>>> d=obj.modified()
>>> d.__class__
<class 'DateTime.DateTime.DateTime'>
>>> d.isoformat()
'2018-01-10T22:11:21+00:00'
>>>
After a 2 line change to Zope DateTime (after all as was said in an old Russian classic, the Brother Karamazope, 'if zod is dead then everything is permitted', but my recollection of this big book could be hazy) all templates could be changed in a future compatible way to enable all this moment.js goodness at least. I changed my one liner to listing.pt so
and it worked just as well. And it will work as well with a datetime type. After all ISO is ISO.
Then your gsoc student could be used to get the Plone calendar better indeed. It is about all right now. It could be great again. That's a more fit task for a student IMO.
