Creation date format

[MartijnMaandag]

Steps to reproduce the issue

I was testing the installation of the Dutch translation package for Joomla 4.2.1 (on a Joomla 4.2.0 site).
Some time ago the creation date in the Translation changed into YYYY-MM, nothing wrong with this, I use this in the translation.
Now I notice that the display in the extension list is changed from YYYY-MM (4.1.x) into YYYY-MM-DD (4.2.x).
This is confusing, if there are two releases in one month (4.2.x) they will have the same time-stamp (2022-08-01) and not 2022-08 like it was, which is less exact.
Attached the screenprints.

Expected result

It is better to have YYYY-MM

Actual result

System information (as much as possible)

J4.2

Additional comments

[richard67]

This is confusing, if there are two releases in one month (4.2.x) they will have the same time-stamp (2022-08-01) and not 2022-08 like it was, which is less exact.

@MartijnMaandag I don't get that. The YYYY-MM format is also only accurate by the month. If you have a release at August 16 and then again at August 23, both will show up as 2022-08-01. The day is added by the display, it seems, but in the XML file where this information comes from, we have only YYYY-MM. So I do not see how that should be more accurate.

[MartijnMaandag]

Well, 2022-08 is the right month and accurate, 2022-08-01 is not the right date and not accurate, this is confusing. I don't know why they changed this from 4.1 to 4.2.

[brianteeman]

its a bug!

[brianteeman]

#27162

[Kostelano]

Yes, this is a bug. Moreover, it spread to all languages ​​(probably), and not just en-GB.

[brianteeman]

The pull request creating this was #27162

There is a very long discussion there regarding this

[Kostelano]

The date format "does not know how" to read such a "truncated" date - for example, 2022-08. It converts it to DATE_FORMAT_LC4.

For example, go to the site/administrator/manifests/packages directory and change the date in the pkg_en-GB.xml file to normal, then return to the Extensions: Manage and press the Refresh Cache button in the toolbar. The date will change back to normal.

[MartijnMaandag]

It is not only the language-packs, we could change them. All core extensions do have the same.

[brianteeman]

did you not read the discussion and pr I linked to #27162

[MartijnMaandag]

Yes, but my first statement that it is confusing is still there.
Why don't we change <creationDate>2022-08</creationDate into <creationDate>2022-08-23</creationDate in the languagepack? Then the actual date is shown and not the fake day 01.

[korenevskiy]

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?

Word and Excel documents store their data in XML. But the contents of the file is a data format, and the text on the Word, Excel screen is a text format. If an Excel cell shows the date in the format "Nov 2022", it does not mean that the data is stored in the same way in the file. If we draw an analogy, then XML is similar to XLSX content, and a website page is similar to an Excel page. It seems to me that there is no reason to even argue. Data should always be stored in a format of its own type.
We can only argue about what format ISO should be converted to for output to display the screen.