@sgiehl opened this issue on July 6th 2015

This PR aims to improve the date & time formats used by Piwik.

:exclamation: This PR will also change most of the visible english date/time formats # Current behavior - Currently there are a few date formats defined in translation strings like CoreHome_DateFormat, CoreCome_MonthLong, CoreHome_ShortWeekFormat and others. Those keys contain placeholders like %shortMonth%, %longYear%, %longDay and others, beeing replaced while getting a localized date. See Date.php Those formats have already been localized to some language. Unfortunately sometimes someone made errors in translating those format strings, which resulted in incomplete/incorrect dates in piwik for that language. - Additionally to those localize-able formats there are quite a few occurrences in the code where the format is directly defined, and thus not language depended. - Names of Months and Days were already translatable before they had been moved to the Intl-Plugin. - Range formats such as the format for a week (CoreHome_ShortWeekFormat) had kind of fixed format patterns, making no difference depending on the range beeing within a month, year or not. - Usage of time format was fixed to H:i:s resulting in not localized time formats # Behaviour with this PR - All date and time formats are now fetched from CLDR, using all additional symbols for all languages - Fixed format occurences in the code have been replaced to use localized formats - Names of Days and Months are still fetched from CLDR, but in both variants. Additionally there is now a "Stand-Alone" variant, which will be used in some formats for some languages or when those names are used as "Stand-Alone" - Range formats are now fetched from CLDR. They now respect the time difference, which means the format differs if the minimal difference is day, month or year Examples for english range formats: - Range within one month: Oct 7 – 13, 2024 - Range within one year Nov 25 – Dec 1, 2024 - Range within more than one year Dec 30, 2024 – Jan 5, 2025 - Time formats are now localized, which also means languages like english are now using the 12 hour format (am/pm)

@mnapoli commented on July 20th 2015

@sgiehl Date formats have changed on master (e.g. http://builds-artifacts.piwik.org/ui-tests.master/14276.7/ActionsDataTable_segmented_visitor_log or http://builds-artifacts.piwik.org/ui-tests.master/14276.7/EvolutionGraph_export_image) is it by any chance related to this (or another PR maybe)? (sorry if I'm a little out of topic :) ) In any case, are the new formats good? (i.e. should I update the screenshots?)

@sgiehl commented on July 20th 2015

@mnapoli That shouldn't be on master, as this PR is not merged. Those screenshots were build on the branch: See https://travis-ci.org/piwik/piwik/builds/71750226

The changes done here are still for discussion. Maybe some formats should be adjusted, but I tried to use those fitting best.

@mnapoli commented on July 20th 2015

Ah thank you, I was tricked by the "PR build" of travis which ends up in the "master" branch in our build-artifacts servers. All good then!

@tsteur commented on July 27th 2015

Just BTW: At some point (for Piwik 3.0 or 4.0) it would be nice to split the Date classes in different classes. Eg Date and DateFormatter or maybe more classes. Using an existing lib would be even better but probably very hard to replace the current one without regressions.

@quba commented on July 27th 2015

We might use something like http://carbon.nesbot.com/

@sgiehl commented on July 27th 2015

@quba that one does not contain any date formats, also the translations are very "minimalistic" @tsteur I had a look at available implementations, but most of them do not contain all we need, and if they contain much more and a very big

@quba commented on July 27th 2015

Understood. So maybe we should create our own library? i know that it's not that easy but would be much better.

@tsteur commented on July 27th 2015

Yeah I thought it will be hard to find one that has all the features we have or to find maybe one that has most features and that we can extend. If we find one it will be hard to replace the lib and to make sure everything still works as our date lib has some "special behaviours" :) I reckon splitting the Date into different classes might be a good start. I'm not sure how well tested it is but shouldn't be too hard to write tests for it so this might be the easiest for now (unless there's a really useful library)

@sgiehl commented on July 29th 2015

@tsteur I've done the commented changes. Btw. I don't think we should merge that for 2.15.0 I guess it would be better for 3.0 as the changes in time/date formats might break some plugins. Should I rebase on the 3.0 branch and issue a new PR for that?

@tsteur commented on July 29th 2015

Merging directly into 3.0 sounds good to me if not needed earlier. Not sure if you have to rebase. Might be possible to just create another PR and select "3.0" there. LGTM

@sgiehl commented on July 29th 2015

Will be rebased and merge to 3.0 branch

This issue was closed on July 29th 2015
Powered by GitHub Issue Mirror