Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: changing image Date added
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.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: changing image Date added
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.
Offline
Re: changing image Date added
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.
Offline
Re: changing image Date added
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Offline
Re: changing image Date added
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: changing image Date added
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 (2025-11-16 18:53:41)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: changing image Date added
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.
Offline
Re: changing image Date added
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: changing image Date added
The main reason we use intl is i18n, since strftime() is deprecated, and date() is English only. As long as only numeric values are present in a date format, we go with date(), which looks pre-Gregorian consistent. But for more localised formats, intl seems unavoidable.
It might be feasible to integrate a switch from Gregorian to Julian calendar for pre-1582 dates, but is it really worth doing? BC era wouldn’t fit into datetime db type anyway.
Offline
Re: changing image Date added
Let’s stick with what we have. If anyone is using pre-Gregorian dates, well, they’ll have to add the calendar attribute to their tags, right?
<txp:date type="image" calendar="julian" ... />
Edit: ugh that’s fine for front side but this is back-end isn’t it. Ignore me. It’s late.
Last edited by Bloke (2025-11-16 23:50:26)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: changing image Date added
A brief test (PHP 8.4): In the images panel, all work as expected. There is a 9 hours difference between the Textpattern time (preference time zone set to UTC) and the MySQL DB time (set to OS time – JPN standard. UTC – 9).
One thing I noted, but perhaps that is not yet fully implemented: I post 3 images in an article (in a <txp:images id="1,2,3" "sort=date asc" /> container), including: Date: <time datetime="<txp:image_date format="iso8601" />"> <txp:image_date /> </time> below the image.
An image dated 2025-09-14 outputs the correct date & time, and so does an image dated 1978-11-09 (timestamp: 1978-11-09T14:22:01+0000, 09 November 1978, 14:22), but the image dated 1925-09-22 15:23:11 (DB time, UTC -9) outputs 01 January 1970, 00:32 (iso8601: 1970-01-01T00:32:05+0000).
Sorting works OK.
But the article date stamps (<txp:posted /> and <txp:modified />) seem wrong (an offset of 18hours behind the real time)?
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: changing image Date added
phiw13 wrote #341210:
… but the image dated 1925-09-22 15:23:11 (DB time, UTC -9) outputs
01 January 1970, 00:32(iso8601:1970-01-01T00:32:05+0000).
Thanks for testing, this issue should be fixed now.
But the article date stamps (
<txp:posted />and<txp:modified />) seem wrong (an offset of 18hours behind the real time)?
This one is amazing, as if the -9 hours offset were applied twice. There are 3 time zones in play:
- php server time zone
- db server time zone
- txp pref time zone
The dates should correspond to the latter, but things can get complicated if the php server does not support all time zones. What does this output for you:
<txp:php>dmp(date_default_timezone_get(), tz_offset());</txp:php>
Offline
Re: changing image Date added
etc wrote #341211:
Thanks for testing, this issue should be fixed now. That would e very valuable addition to Textpattern I think.
Yes! Now that looks nice across the board I think.
This one is amazing, as if the -9 hours offset were applied twice. There are 3 time zones in play:
- php server time zone
- db server time zone
- txp pref time zone
The dates should correspond to the latter, but things can get complicated if the php server does not support all time zones. What does this output for you:
<txp:php>dmp(date_default_timezone_get(), tz_offset());</txp:php>…
UTC
0
Quick test: As soon as I set the TXP pref to Tokyo instead of UTC then article dates are correct – both 4.9rc2 basic install and a 5.0-dev basic install (both have the very minimal configuration).
On two live servers, Singapore and Hong Kong based (UTC-8) the TXP (4.9) pref is set to “Tokyo” with no errors.
The local server php.ini has date.timezone = Asia/Tokyo.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: changing image Date added
phiw13 wrote #341213:
Quick test: As soon as I set the TXP pref to
Tokyoinstead of UTC then article dates are correct – both 4.9rc2 basic install and a 5.0-dev basic install (both have the very minimal configuration).
You mean the dates are correct in Tokyo time? Then, when the pref was set to UTC, they were correct (-9 hours) in UTC time, or the offset was double?
Offline