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_ShortWeekFormat and others. Those keys contain placeholders like
%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)
@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?)
@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.
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!
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.
We might use something like http://carbon.nesbot.com/
@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
Understood. So maybe we should create our own library? i know that it's not that easy but would be much better.
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)
@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?
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
Will be rebased and merge to 3.0 branch