Fix strtotime() warnings on PHP 8

[SharkyKZ]

Summary of Changes

Removes use of strtotime() in favor of string comparison for dates.

Testing Instructions

Use 32-bit version of PHP 8.0.0 RC1 or newer dev build.
Create an article. Don't set Finish Publishing date.
View article list/blog/featured view containing the article in frontend.
View the article in frontend.

Actual result BEFORE applying this Pull Request

Warning: strtotime(): Epoch doesn't fit in a PHP integer

Expected result AFTER applying this Pull Request

No warnings.

Documentation Changes Required

No.

[richard67]

Unfortunately I don't have the required testing environment, 32-bit version of PHP 8.0.0 RC1 or newer dev build.

But from code review it's absolutely clear what this PR does, and it makes sense, first check for the null date and then to a strtotime for the other check, and not vice versa.

@HLeithner What do you think? Would you count a good code review as a good test, too?

[infograf768]

@SharkyKZ
Can you also fix it here

joomla-cms/components/com_contact/tmpl/category/default_items.php

Lines 113 to 126 in a1ecbc2

	<?php if (strtotime($item->publish_up) > strtotime(Factory::getDate())) : ?>
	<div>
	<span class="list-published badge badge-warning">
	<?php echo Text::_('JNOTPUBLISHEDYET'); ?>
	</span>
	</div>
	<?php endif; ?>
	<?php if (!is_null($item->publish_down) && strtotime($item->publish_down) < strtotime(Factory::getDate())) : ?>
	<div>
	<span class="list-published badge badge-warning">
	<?php echo Text::_('JEXPIRED'); ?>
	</span>
	</div
	<?php endif; ?>

[SharkyKZ]

@infograf768 Will do. But I'm starting to question the validity of this fix. It has a limited range:

The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.)

I guess we should account for values outside this range?

[infograf768]

I was born after 1901 and 2038 would mean I would be 90. Can't project so far. ;)
But this says that anyway code will have to be modified in 2038.
https://www.unixtimestamp.com/ (unix starts in 1970 btw)

https://en.wikipedia.org/wiki/Year_2038_problem

[SharkyKZ]

Do we even need strtotime() here? Looks like we could be comparing date strings instead.

[richard67]

Do we even need strtotime() here? Looks like we could be comparing date strings instead.

@SharkyKZ Where do you mean? For the greater than or lower than comparisons we can only use strings if we can 100% be sure that they are in ISO format.

[SharkyKZ]

Dates returned from the databases should always be the same format, right?

[richard67]

@SharkyKZ Yes, but the question is not if it is the same format always but if this format means that alphabetical sorting is equal to sorting by date and time, and this is not given for a format like e.g. "DD.MM.YYYY hh:nn:ss". Alphabetical sorting is only equal to sorting by date and time if the order of the time periods "year, month, day ... seconds" is either ascending or descending with the length of these periods, and if the number of digits used for each period is always the same, i.e. it will not work when using only 1 digit for months 1 to 9.

So the ISO formats (short or long) fulfil this, they go from year down to second: "YYYY-MM-DD hh:mm:ss".

It would theoretically also work with "ss:mm:hh DD-MM-YYYY", but nobody really uses that.

So if you can be 100% sure that the string representation is always the same ISO format, then you can compare strings like times.

But if not, then you have to force this format.

[SharkyKZ]

But dates from the database are always going to be in YYYY-MM-DD hh:mm:ss (or Y-m-d H:i:s in PHP terms) format across all supported databases and locales?

[richard67]

But dates from the database are always going to be in YYYY-MM-DD hh:mm:ss (or Y-m-d H:i:s in PHP terms) format across all supported databases and locales?

@SharkyKZ Exactly that's what I'm not 100% sure about. At least on MS SQL Server it might be different.

[richard67]

@SharkyKZ I'd stay with the strtotime to play safe.

[SharkyKZ]

We can't use strtotime() because of the limitations. And we do only support Y-m-d H:i:s format for database dates. Database API can support different formats but this doesn't concern the CMS.

[infograf768]

#30921 (comment)

[SharkyKZ]

I'll do that later. It's for 4.0 anyways. There's also same issue in calendar field on 4.0.

[roland-d]

Like Richard I don have a 32-bit environment either, who does 🤔 However code review looks good.

[HLeithner]

@roland-d can you test on a 64bit system?

[bayareajenn]

also @roland-d will you see if Patch Tester gives you this PR in PHP8? :)

[bayareajenn]

I have tested this item ✅ successfully on bbcb7bf

I tested on 64 bit PHP8. Added article. Added cat blog, cat list, single article, featured on the frontend. No errors. Couldn't find it broke anything.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30921.}

[ghost]

I have tested this item ✅ successfully on bbcb7bf

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30921.}

[richard67]

@Gostn Which PHP version did you use? 8? If so: 32 or 64 bit?

[ghost]

ups i forgot i'm a troll #30716 (comment)

[HLeithner]

ups i forgot i'm a troll #30716 (comment)

not sure what you mean with this but in this case it's important to know which version you tested. (I mean it's always a useful information)

[ghost]

if you read the comment you wll understand that asking by one who call you a troll is …

[HLeithner]

ok @Gostn but still no answer for the version

[richard67]

Exactly this behaviour was what I've meant.

[ghost]

ok @Gostn but still no answer for the version

as long as i´m called a troll and no apologize for that …

[richard67]

RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30921.}

[HLeithner]

Thanks