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
CoreHome_ShortWeekFormatand others. Those keys contain placeholders like
%longDayand others, beeing replaced while getting a localized date. See Date.php
CoreHome_ShortWeekFormat) had kind of fixed format patterns, making no difference depending on the range beeing within a month, year or not.
H:i:sresulting in not localized time formats
Oct 7 – 13, 2024
Nov 25 – Dec 1, 2024
Dec 30, 2024 – Jan 5, 2025
@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?)
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.
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