Do we really need to know the day?

Also it introduces an inconsistency as all the other files use Month Year as their creationDate.

Personally I don't care much how it is done. But I see indeed advantages in it.

• I think the day is part of a date and should be there. I don't see a reason to not show it, especially since it is part of a script.
• The current way is using english words which aren't translated. The proposed way would be language independent. It could even be translated into different formats and used to sort the list, if we ever want to do that (and get extensions to consistently use it).

I understand and appreciate the issue with it being in English. However for me the problem is

1. Consistency as explained above
2. Clarity - is 2019-1-11 the first of November or the eleventh of January.

2 is exactly the reason for the ISO standard to get rid of that confusion
og which is which. Y-M-D :)
Good call by the translators.
Would be fine if the older are updated for consistency

On Wed, Nov 27, 2019 at 8:58 AM Brian Teeman notifications@github.com
wrote:

I understand and appreciate the issue with it being in English. However
for me the problem is

1. Consistency as explained above
2. Clarity - is 2019-1-11 the first of November or the eleventh of
   January.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/joomla/joomla-cms/pull/27162?email_source=notifications&email_token=AAGA7LM74XLRIVK25IG4DLLQVYSD7A5CNFSM4JR6TUW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFIUJJI#issuecomment-558974117,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGA7LLI2HPMZVXYKTDB6Y3QVYSD7ANCNFSM4JR6TUWQ
.

Try explains that to the people who live in the USA

why to have 2 format ?
one for 'reldate' => date('j-F-Y'),
and another one for 'credate' => date('Y-m-d'),

I am a bit confused.
How would such dates be translated in the language packs xmls as we can enter whatever we want there?

How would such dates be translated in the language packs xmls as we can enter whatever we want there?

The point is that you are not supposed to enter whatever you want. According to the forum post by Mig. :)
I'm not saying we're going to translate them. I just say it could be done if at least the majority would follow that format.

I just say it could be done if at least the majority would follow that format.

and all of the core xml would need to be updated (they are not covered by the bump script) and I still say it is more confusing to have 2019-1-11

I still say it is more confusing to have 2019-1-11

The format Y-d-m isn't used in that many countries. According to Wikipedia it's only 4 countries. So my guess would be most would read that date as January 11, 2019.

Rewriting all the other core XMLs would be rather simple, I can do that of course. My initial goal was just the language pack files so they follow what the translators have as their guidelines.

Would be nice to have it fully covered. The English text currently from the
XMLs are only of use to some while the ISO standard is of use to everyone :)

On Wed, Nov 27, 2019 at 10:57 PM Thomas Hunziker notifications@github.com
wrote:

I still say it is more confusing to have 2019-1-11

The format Y-d-m isn't used in that many countries. According to Wikipedia
it's only 4 countries. So my guess would be most would read that date as
January 11, 2019.

Rewriting all the other core XMLs would be rather simple, I can do that of
course. My initial goal was just the language pack files so they follow
what the translators have as their guidelines.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/joomla/joomla-cms/pull/27162?email_source=notifications&email_token=AAGA7LI2VB5AVTKSRF4C4M3QV3ULHA5CNFSM4JR6TUW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFK3DUY#issuecomment-559264211,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGA7LIT57S2J4X3RUN4AU3QV3ULHANCNFSM4JR6TUWQ
.

Might only be 4 countries but it's a significant % of users

Might only be 4 countries but it's a significant % of users

I honestly don't know how that equates to user. Countries are Kazakhstan, Latvia, Nepal and Turkmenistan.
On the other hand, using an english word for the month isn't that inclusive either.

I will expand this PR so it includes all created dates. And I'll have a look at how work it would be to make it translateable and sortable.

Using an ISO standard is a good move. Since today I'm using the day also in my releases. If accepted extension devs can follow it.

I've expanded this PR so it changes all creationDate instances to the ISO format.
I've also added sorting by date to the extension manager and the date will be shown "translated" where possible (depending on the source format of the date).

Obviously, sorting by date doesn't work properly for the dates that aren't entered by the ISO format. This gives a gentle push to extension devs to also use the ISO format for the date.

I stand by the comment that this will cause confusion as people wont know what month 2019-11-1 is

I stand by the comment that this will cause confusion as people wont know what month 2019-11-1 is

The date is now shown localised in the format by the active language. So no confusion anymore.

english:

german:

You are assuming that everyone has the correct language pack installed. For example there have only been 6000 downloads of the US-English

Test needs to be fixed when we go this way:

1) JInstallerManifestLibraryTest::testLoadManifestFromData

Failed asserting that two strings are equal.

--- Expected

+++ Actual

@@ @@

-'2008'

+'2008-01'

You are assuming that everyone has the correct language pack installed.

No, I'm not assuming this.
But if people would really get confused with the date format, then there would be an easy solution available by installing and selecting the language.

Test needs to be fixed when we go this way:

Test fixed.

Rebased and conflicts solved

I have tested this item 🔴 unsuccessfully on f9ed44b

Didn't make any difference after applying the patch via patchtester. Nor did it respect the currently language after I set us english as default.

That the date format didn't change with US English is actually due to the US Englisch language pack being faulty. The respective language string is DATE_FORMAT_LC4="Y-m-d". Same as in en-GB. I think in US you use "Y-d-m" instead?
If you adjust that string in the en-US.ini file (or by using a language override) it should work.

Also, it may be necessary to select all extensions and hit the "Refresh Cache" button so the creation dates are updated from the XMLs.

Using the patchtester I got the message:
The file marked for modification does not exist: administrator/components/com_installer/models/extension.php

@chmst This PR is for J3 and not J4.

That the date format didn't change with US English is actually due to the US Englisch language pack being faulty. The respective language string is DATE_FORMAT_LC4="Y-m-d". Same as in en-GB. I think in US you use "Y-d-m" instead?

nope, we use m-d-Y

Also, it may be necessary to select all extensions and hit the "Refresh Cache" button so the creation dates are updated from the XMLs.

shouldn't the "january 2020" have changed to numeric?

I have tested this item ✅ successfully on f9ed44b

@N6REJ
There is no more "january 2020" after patch.

i've not runned the bump script
when i sort let's say for date descending the result is incorrect

when i sort let's say for date descending the result is incorrect

I must say I did not test that.

probably because the date is being sorted by the stored value and not the displayed value

Make sure to select all extensions and use the "Refresh Cache" button. That is because the dates from the XMLs are stored in the database. When I changed the XMLs, the database isn't automatically updated and thus still has the old values.
I think the database is updated during the update process, but honestly I'm not sure about that. Maybe someone else knows.

Sorting by date works here (I had refreshed cache).
Evidently, if the xml has not been modified (for example patchtester or Installation from web), we have weird results.

Merged current staging and resolved conflicts

Is there any interest in getting this into core? If so, I can update the branch, otherwise I would close it.

Perhaps more for 4.1?

Sure, for 4.0 it's to late 😄

Would be nice to rebase for 4.1 and then get another round of testing.

Is there any interest in getting this into core? If so, I can update the branch, otherwise I would close it.

Yes, please update the PR for 4.1.

I've tried on my laptop, but messed it up somehow with the conflict resolving. I need to do it when I'm back home.

Recreated for 4.1 as there were two many changes between 3.10 and 4.1. It was easier to cherrypick the things I need and redo the rest manually.
I couldn't test it yet myself but it should work the same as before.

@Bakual can you fix the conflicts and then hopefully we will find testers for this one as it is a nice change.

Rebased to 4.2 and solved conflicts.

Found a few more creationDates. Should be ready for testin again.

Thanks. There are still some conflicts in installation and api.

Richard promised me they will be gone once 4.1 is merged up into 4.2 next time.

Tried again and changed the 2005-01 date to 2005-08 so it matches the Joomla release

I have tested this item ✅ successfully on ea91a81

I could not install a language as they do not exist for 4.2 but I did a language override of the constant DATE_FORMAT_LC4 and then the date in the extension manager has changed.

@Bakual Is the description of this PR still right? It says:

Initially this PR only changed the build script and the XMLs updated by it. I've expanded it now so it contains all core XML files.

But in the changes I cannot find any change in the build script.

Looks like it got lost during the several redoing/conflict solving of this PR.

Added back the changes in the bump script.

I have tested this item ✅ successfully on ae3da48

I tested it again with a language override of the constant DATE_FORMAT_LC4 and then the date in the extension manager has changed. Run also the buzmp script php build/bump.php -v 4.2.9 and then the first entry showed version 4.2.9 with the current date.

The first entries are listed from 2004, is this correct?

The first entries are listed from 2004, is this correct?

I didn't validate the dates. I just took what was there and changed the format. 😄

Run also the buzmp script php build/bump.php -v 4.2.9 and then the first entry showed version 4.2.99 with the current date.

@laoneo I hope this is a typo and the patch version was not changed from 9 to 99.

Yes sure was a typo, just wanted to make sure it used my bump version.

Merged upstream and solved conflicts

Thanks everybody.

Wohoooo! 🕺🏻

Nice!!

It's obvious. An XML file is a data storage format. I repeat this is the data format. XML tags can store any type of data. If only the "CreationDate" tag is a text type, then the format of this tag is obvious, but if the "creation Date" tag is a date type, then this implies the format in ISO. If we remember that XML is a data format, and XML is not a text document of articles. XML is a data warehouse, just like SQL is a data warehouse. The difference is that SQL is data processing and storage, and XML is just data storage.
But let's look at this problem from the other side. Third-party developers can create components for sorting by date tag.
Even if there is no sorting in Joomla, the data storage format must match the content.
We store data in SQL in ISO format. Maybe we will store data in SQL in the "Nov 2022" format?