No Code Attached Yet
avatar JackJoeJack
JackJoeJack
15 Mar 2024

Steps to reproduce the issue

Create an article (the category is irrelevant)
Go to the created date field inside the "publishing" tab, and insert the following date and time: 1932-09-26 00:03:00
Read the MySQL database (version 8.0.27) using an app or some way that allows you to view the table, select that record in the #__content table, and notice that the value in the "created" column.

Expected result

1932-09-26 00:03:00

Actual result

1932-09-25 23:03:00

System information (as much as possible)

Joomla 5.0.3, no relevant extensions
Server:
MAMP 6.8 (Apache/2.4.54 (Unix)), WebServer to PHP Interface: cgi-fcgi, PHP 8.2.0, MySQL database (version 8.0.27) via DBNgin

Additional comments

As you can see, there is less one hour compared to the original inputed field, but if we go to older dates (ex: 1532-09-26 00:03:00) the recorded value is this: 1532-09-26 00:39:45

I found out that starting from the date 1976-09-26 it matches what is at the field and what is at the database.

What puzzles me is that this date (1976-09-26) has nothing to do with the unix epoch or anything relevant.

This behaviour is the same for the other date fields at the "pubishing" tab.

I've also tested this in Joomla 4.4.3 and the issue also exists.

avatar JackJoeJack JackJoeJack - open - 15 Mar 2024
avatar JackJoeJack JackJoeJack - change - 15 Mar 2024
Labels Removed: ?
avatar joomla-cms-bot joomla-cms-bot - change - 15 Mar 2024
Labels Added: No Code Attached Yet
avatar joomla-cms-bot joomla-cms-bot - labeled - 15 Mar 2024
avatar alikon
alikon - comment - 16 Mar 2024

unable to replicate
image

what tool are you using to view the value in the "created" column?

avatar alikon alikon - change - 16 Mar 2024
Labels Added: Information Required
avatar alikon alikon - labeled - 16 Mar 2024
avatar JackJoeJack
JackJoeJack - comment - 16 Mar 2024

Please test with Joomla 4.4.3 or Joomla 5.0.3!

Your table prefix made me think that your Joomla version is 5.1.0 and I downloaded it and tested, and I can confirm that it is fixed in 5.1.0!

I am testing with phpMyAdmin, but a query with a SELECT with PHP or via CLI gives me the same wrong result, but as I discovered today, only in versions prior to J!5.1.0

avatar alikon
alikon - comment - 16 Mar 2024

done with both latest 4.4.x and 5.0.x and it works as expected

avatar JackJoeJack
JackJoeJack - comment - 16 Mar 2024

done with both latest 4.4.x and 5.0.x and it works as expected

Thanks for the test, we need to find out what is different between my version and yours.
I'm going to install a clean version of Joomle 5.0.x and see if that happens.
Could you please test with phpMyAdmin?

avatar JackJoeJack JackJoeJack - change - 16 Mar 2024
The description was changed
avatar JackJoeJack JackJoeJack - edited - 16 Mar 2024
avatar alikon
alikon - comment - 16 Mar 2024

image

done with 5.2.0

avatar JackJoeJack
JackJoeJack - comment - 16 Mar 2024

Thanks for the test, I can also confirm that a clean version of Joomla 5.0.3 is also working correctly!
This means that I have something that is changing the dates in my sites that are "affected", I'm going to disable everything and test until I find out what is doing this.
As soon as I have a result I'll post here for others to know what could make this.

avatar JackJoeJack
JackJoeJack - comment - 16 Mar 2024

I found out what is changing this!!
It is the timezone at the configuration.
If I have UTC it behaves correctly, but if I change it to "Lisbon" it will have this issue!!

Maybe this is the way it should be? account for the timezone change?

avatar brianteeman
brianteeman - comment - 16 Mar 2024

datetime is always stored as utc

what is confusing is that you posted an example where the difference did not match

As you can see, there is less one hour compared to the original inputed field, but if we go to older dates (ex: 1532-09-26 00:03:00) the recorded value is this: 1532-09-26 00:39:45

avatar JackJoeJack
JackJoeJack - comment - 16 Mar 2024

Indeed, I re-tested in Joomla 5.1.0 (the latest beta) and changed the timezone to "Lisbon", and the date "1532-09-26 00:03:00" was re-saved and at the db I can see "1532-09-26 00:39:45" this is a weird change.

Also, why is this happening to dates before 1976-09-26?

avatar richard67
richard67 - comment - 16 Mar 2024

The ICU Library respective the Time Zone database (formerly known as Olson database) which is used by many software projects like PHP or databases and also by Linux operating systems uses the local time as determined by the particular city for historic dates which are older than the invention of time zones. I don't remember the date now, but 1532 is surely before that, so you get the local time of Lisboa determined by the longitude difference to Greenwich meridian. That explains the change from "00:03:00" = time entered in Lisboa local time to "00:39:45" in UTC, as Lisboa is west of Greenwich.

You can find more information here https://data.iana.org/time-zones/tz-link.html .

avatar JackJoeJack
JackJoeJack - comment - 16 Mar 2024

Thanks for that explanation, but what happened on the 1976-09-26 to match the dates?

avatar richard67
richard67 - comment - 16 Mar 2024

Well, that's the only remaining question. Everything else should be clarified.

avatar richard67
richard67 - comment - 16 Mar 2024

The IANA Time Zone Database rules for Lisboa can be found here: https://github.com/eggert/tz/blob/main/europe#L2157-L2164

So anything before January 1, 1912, goes to local time with an offset of -0:36:45 to UTC.

On 1976-09-26 at 1:00 was a time zone change from WET/WEDT to CET, very likely due to a law change.

The rules which belong to that table you can just find in the lines above the ones I've linked.

So to me all seems to be as expected.

avatar richard67
richard67 - comment - 16 Mar 2024

They changed rule on 1966-04-03, then again on 1976-09-26, then again later a few times until the current EU daylight saving time rules applied in 1996.

avatar JackJoeJack
JackJoeJack - comment - 16 Mar 2024

Stellar research, find and explanation @richard67 !
Thank you very much for clearing this.

I would also like to thank @alikon and @brianteeman for the time they invested in helping solve this issue!

avatar JackJoeJack JackJoeJack - change - 16 Mar 2024
Status New Closed
Closed_Date 0000-00-00 00:00:00 2024-03-16 11:11:08
Closed_By JackJoeJack
avatar JackJoeJack JackJoeJack - close - 16 Mar 2024
avatar richard67 richard67 - change - 16 Mar 2024
Labels Removed: Information Required
avatar richard67 richard67 - unlabeled - 16 Mar 2024

Add a Comment

Login with GitHub to post a comment