changing image Date added

Bloke · Yesterday 14:59:09

etc wrote #341183:

Could date input be put immediately after the image name (and before the category), for consistency with articles?

We could. I only put it down there because I deem it not as important as alt and caption. Will take the consensus.

phiw13 · Today 02:42:08

I’d go for consistency with the Files panel, where the data (Published) comes after the description.

BTW – did I test it correctly, I can change the data (now, future or past) but only back to 1970-something, not ealier ?

I had that faint hope to inout the real date for the image (e.g creation, copyright) and get rid of my date custom-field – e.g images that have been created between 1923-28…, looks like I am out of luck there.

Bloke · Today 07:16:30

Better date handling is something I’d like to be able to offer but I don’t know how to go about it. MySQL can store old dates in the Date field (and by inference DateTime?) but I suspect the fact we convert it to a Unix timestamp for timezone conversion and calculation purposes is scuppering things, as that means it can only go back as far as 1970.

Any thoughts on this, Oleg? It would be nice to be able to offer a more full date range.

phiw13 · Today 07:30:54

Image Edit panel bugs ?

Bug [1] If I change the date to something pre_Unix_time, say 1925 / 12/ 12, Textpattern let me save that (the message-pane is green with the reassuring “Images updated: image_name.webp” message). But the listed date on the list panel, and the Published date field on the Edit image panel on a return visit, is not modified – the previous value is retained (as expected, given current limitations). The Write panel in comparison does not let me save that 100 year old date (error message-pane, invalid date or time).

Bug [2] On a live site I have 3 custom fields (jcr_image_custom plugin) listed under the description field. After updating to the latestcode the Published date block is added, after my custom fields. Not sure if this is really a bug or something of a weirdness.

Bloke wrote #341193:

Better date handling is something I’d like to be able to offer but I don’t know how to go about it. […]

It would be nice to be able to offer a more full date range.

+ 10.

etc · Today 11:37:23

Bloke wrote #341193:

I suspect the fact we convert it to a Unix timestamp for timezone conversion and calculation purposes is scuppering things, as that means it can only go back as far as 1970.

Yep, we use unix timestamps for tz conversion, especially when php and db servers are in different timezones. The joybreakers are mysql UNIX_TIMESTAMP() and FROM_UNIXTIME() functions that do not support negative timestamps. There should be a way around it (CONVERT_TZ()?), but we use these functions all over the code, so this would require much testing.

etc · Today 12:39:46

Well, let us test pre-1970 dates (only images atm) in cf-branch. Might yet be pushed to 4.9 if everything is fine.

Unfortunately, I have no different-tz php and db setup at hand. If anybody has, please test.

Public dates might be wrong, since they are not (have never been?) tz-converted from db to php.

Bloke · Today 12:52:10

etc wrote #341199:

I have no different-tz php and db setup at hand.

I do. Will play this afternoon, thanks for the test. If this works, we should add the 1970-01-01 00:00:00 to constants.php and roll it out to 4.9.0.

Public dates might be wrong, since they are not (have never been?) tz-converted from db to php.

Yes. This is what I’ve noticed. I think gtime() is defective and doesn’t take offsets into account, probably because we’ve never had much need to display image dates on the public site.

I might be wrong about that function but I can’t see any conversion taking place.

etc · Today 13:59:35

Bloke wrote #341200:

If this works, we should add the 1970-01-01 00:00:00 to constants.php and roll it out to 4.9.0.

It does not, but FROM_UNIXTIME(0) seems to work, at least when php and db share the timezone. We should probably cache it somehow.

Bloke · Today 18:18:07

So here’s a test I did on the CF branch with an image, on localhost (MAMP) :

Upload png image. Date is set to today.
Edit image. Set date to 1066-10-14 11:12:13 and Save (That’s the Battle of Hastings, which predates the Gregorian calendar that began in 1582). There have been 108 Leap Years between 1583 and 2025.
Clicking back into the Image Edit panel shows the date correctly: 1066-10-14 11:12:13.
Directly inspecting the database txp_image Date column: 1066-10-14 12:12:13. (1 hour later)
On Content > Images panel, the date in the Images list shows: 08 Oct 1066 11:12 AM. (6 days previously)
Searching for 1066-10-08 on the Images panel yields nothing.
Searching for 1066-10-14 on the Images panel returns the sole entry with the date shown as 1066-10-08.
On the front-end website, using <image::info type="date" /> shows 1066-10-14 12:12:13 (1 hour later than the desired time, presumably taken directly from the database with no TZ compensation).
Trying to set a date pre-1970 for an article, of course, fails to save at present.

Relevant diagnostics (UK time now 17:57:43) :

PHP version: 8.3.14
GD Graphics Library: bundled (2.1.0 compatible); Supported formats: GIF, JPEG, PNG, WebP.
Server time zone: UTC
Server local time: 2025-11-16 17:57:43
Daylight Saving Time enabled?: 0
Automatically adjust Daylight Saving Time setting?: 0
Time zone (GMT offset in seconds): UTC (+0)
MySQL: 5.7.44 (MySQL Community Server (GPL)) 
Database server time: 2025-11-16 17:57:43
Database server time offset: 1 s
Database server time zone: SYSTEM
Database session time zone: SYSTEM
Locale: en_US.UTF-8
Site / Admin language: en / en
Web server: Apache/2.4.62 (Unix) OpenSSL/1.1.1w mod_fastcgi/mod_fastcgi-SNAP-0910052141

About 20 minutes later at 18:15:16, I repeated the above with an online server in Germany. It yielded identical results for all tests. The same hour dicrepancy in the database and front-end. The same 6-day discrepancy in the Image List.

These are the relevant diagnostics:

PHP version: 8.3.27
GD Graphics Library: bundled (2.1.0 compatible); Supported formats: GIF, JPEG, PNG, WebP, AVIF.
Server time zone: UTC
Server local time: 2025-11-16 18:15:16
Daylight Saving Time enabled?: 0
Automatically adjust Daylight Saving Time setting?: 0
Time zone (GMT offset in seconds):  (+3600)
MySQL: 10.11.14-MariaDB-0+deb12u2 (Debian 12) 
Database server time: 2025-11-16 19:15:16
Database server time offset: 0 s
Database server time zone: SYSTEM
Database session time zone: SYSTEM
Locale: en_US.UTF-8
Site / Admin language: en / en
Web server: Apache

So, ummm, I’m officially baffled.

Bloke · Today 18:48:10

Wait, okay, this might explain it.. Check this freaky stuff out: only dates before 1582 screw up on the Image List panel.

That’s understandable, since they pre-date the introduction of the Gregorian calendar. BUT they don’t fail in quite the way I’d expect. If I vary the image Date as shown in the left column, starting in the year ‘1’ (0001) and increasing the value by 100 years each time, the Image List panel reports the date as given in the 2nd column:

Image Date Year value	List panel reports
0001	16 Oct 1 11:12 AM
0101	15 Oct 101 11:12 AM
0201	14 Oct 201 11:12 AM
0301	13 Oct 301 11:12 AM
0401	13 Oct 401 11:12 AM
0501	12 Oct 501 11:12 AM
0601	11 Oct 601 11:12 AM
0701	10 Oct 701 11:12 AM
0801	10 Oct 801 11:12 AM
0901	09 Oct 901 11:12 AM
1001	08 Oct 1001 11:12 AM
1101	07 Oct 1101 11:12 AM
1201	07 Oct 1201 11:12 AM
1301	06 Oct 1301 11:12 AM
1401	05 Oct 1401 11:12 AM
1501	04 Oct 1501 11:12 AM
1601	14 Oct 1601 11:12 AM
1701	14 Oct 1701 11:12 AM
1801	14 Oct 1801 11:12 AM
1901	14 Oct 1901 11:12 AM
2001	14 Oct 2001 11:12 AM

…

Looks like the days go back by one every 100 years except on the 400 year markers where it stays the same. Reminiscent of something leap yearish…? And then as soon as the Gregorian calendar is introduced, it works fine.

So if we’re dealing with dates before 1582, we need to either fudge them to remove leap years, or switch calendar system.

Not sure I have the mental capacity to figure out how to store a BC date less than zero. I think that might be the limit, so most of the Greek Empire is out :)

Last edited by Bloke (Today 18:53:41)

etc · Today 21:01:55

Nice sleuthing and funny results! I guess it’s php IntlGregorianCalendar playing tricks. As soon as I replace the date format in gTime($uDate) (which is a mere safe_strftime('%d %b %Y %X', $uDate) alias and uses intl) with %Y-%m-%d (which does not call intl functions), the image dates output looks consistent.

This is kinda annoying, since switching the format of old dates via safe_strftime() can alter the output value of the dates themselves. Bummer.

Bloke · Today 22:52:51

Urk, yeah. Hmmm. What’s the best course of action here? I mean, since we’ve never really exposed the dates properly we could probably get away with showing them consistently without intl. Would anyone notice the odd hour or three discrepancy if the result was more consistent?

And also, since we’ve never allowed dates prior to 1970 before, nobody would have any old dates to compare.

Textpattern CMS

Textpattern CMS support forum

#13 Yesterday 14:59:09

Re: changing image Date added

etc wrote #341183:

#14 Today 02:42:08

Re: changing image Date added

#15 Today 07:16:30

Re: changing image Date added

#16 Today 07:30:54

Re: changing image Date added

Bloke wrote #341193:

#17 Today 11:37:23

Re: changing image Date added

Bloke wrote #341193:

#18 Today 12:39:46

Re: changing image Date added

#19 Today 12:52:10

Re: changing image Date added

etc wrote #341199:

#20 Today 13:59:35

Re: changing image Date added

Bloke wrote #341200:

#21 Today 18:18:07

Re: changing image Date added

#22 Today 18:48:10

Re: changing image Date added

#23 Today 21:01:55

Re: changing image Date added

#24 Today 22:52:51

Re: changing image Date added

Board footer