event_view.pt: start/end time not localized if start date equals end date (suggested fix included)

[kleist]

Plone 3.1.6

In "Products/CMFPlone/skins/plone_content/event_view.pt", the block "tal:sameday" doesn't use toLocalizedTime() as the block "tal:differentday" does.

Suggested fix:

92c92,94
<                                         tal:replace="python:test(ampm, here.start().AMPMMinutes(), here.start().TimeMinutes())">Start Time</span>
---
>                                         class="explain"
>                                         tal:content="python:here.toLocalizedTime(here.start(),
>                                         long_format=1).split()[1]">Start Date Time</span>
106c108,110
<                                         tal:replace="python:test(ampm, here.end().AMPMMinutes(), here.end().TimeMinutes())">End Time</span>
---
>                                         class="explain"
>                                         tal:content="python:here.toLocalizedTime(here.end(),
>                                         long_format=1).split()[1]">End Date Time</span>

I'm not the man to say if the use of split() and slicing is robust enough to extract just the time in all locales. Is it RTL safe?

Aside: It would really be nice if toTocalizedTime() had a parameter to return the time only.

[tomster]

I can't see any fault in the current implementation. Afterall, these two types of events *do* require different treatment. For an event that begins and ends on the same day, we only need to display the time for the ending, whereas for a multi-day event we need the full date/time info for start and end.

[kleist]

I failed to describe the bug clearly:

When start and end date are the same, the start/end times are not localized. For example: on a German Plone site, "1.23 PM" is rendered instead of the excepted "13:23".

[tomster]

gotcha. (i tested with an english locale, so everything seemed right to me). i'll take another look.

[jnelson]

Patch to add localized time capabilities

[jnelson]

I've attached a patch to allow the getLocalizedTime() function to provide just the localized time if the 'time_only' flag is set.

Tested, working on 3.2 dev buildout.

[jnelson]

Updated patch to use propertiestool for default time

[jnelson]

Propertiestool code works - languages without a defined localized time get the format specified in the propertiestool.

[calvinhp]

(In [24257]) * Added time_only for use with toLocalizedTime so that event_view now localizes the start/end times if the start/end dates are the same.

• Added migration for 3.2 to 3.2.1 to add new property to the propery tool.
• Added new time_format id to the po files to support the new time_only fix
• thx jnelson, fixes #8607

[calvinhp]

(In [24290]) merged r24256:24257 from the 3.2 branch down to trunk, thx jnelson, refs #8607

[calvinhp]

(In [24291]) merged r24256:24257 from the 3.2 branch down to trunk, thx jnelson, refs #8607

[calvinhp]

(In [24292]) merged r24256:24257 from the 3.2 branch down to trunk, thx jnelson, refs #8607

[vincentfretin]

The migration profile 3.2 -> 3.2.1 don't work, python code is missing to activate this migration profile I think. So after portal_migration, you don't have localTimeOnlyFormat property in site_properties, and so viewing an event fail with AttributeError: localTimeOnlyFormat.

[vincentfretin]

Fix migration to Plone 3.2.1

[vincentfretin]

Please apply the patch as soon as possible. :-)

[vincentfretin]

fix toLocalizedTime call in DocumentBylineViewlet viewlet (plone.app.layout egg)

[vincentfretin]

There is another problem in the DocumentBylineViewlet viewlet included at the top of each page. The viewlet call toLocalizeTime with as third argument the context, but now the third argument is time_only! So we need to specify a named argument for the context here. Please see the patch.

[MatthewWilkes]

Split the migration issue out into #8939 as it's critical. The DocumentBylineViewlet is less serious and does fit in this trac, imo.

[encolpe]

Ok guys, I add this last patch. Now, if you have a new bug it is better to provide a test (functional or unit) than a patch.