strftime unix %s doesn't works on localhost

Bloke · 2020-06-08 15:49:41

Thanks for the tabulation, Pete.

This is crazy.

On any article page/form under a MySQL 8 environment:

<txp:php>
echo strftime('%s', 1591628404);
</txp:php>

EXPECTED: 1591628404
ACTUAL: -1

That’s a direct PHP function call, not even going through any of our tag code. If you use any other format than %s, it works fine and converts it.

Question is: why?

EDIT: being purist about it, asking strftime() to return the unix timestamp and passing in the unix timestamp is pretty useless. We already know it, as we’re passing it in! So, worst case scenario is we detect %s as a format string and just return the direct article timestamp + timezone offset.

gaekwad · 2020-06-08 15:54:36

Running this…:

<txp:php>echo time();</txp:php>

…returns the epoch (expected). I can switch one or more of the demo servers to PHP 7.3, any good?

Bloke · 2020-06-08 16:00:08

gaekwad wrote #323643:

I can switch one or more of the demo servers to PHP 7.3, any good?

Perhaps so we can rule out or confirm PHP 7.4, that might be useful. Thank you.

I can’t see why the MySQL version would have any bearing on this since using the PHP strftime() function directly wth a fixed value (string or int) triggers the -1 output. That has nothing to do with MySQL at all.

Last edited by Bloke (2020-06-08 16:00:57)

gaekwad · 2020-06-08 16:04:53

Bloke wrote #323644:

Perhaps so we can rule out or confirm PHP 7.4, that might be useful. Thank you.

OK, I’ll wait until the latest compile has finished, then push a 7.3 latest compile through, and I’ll update this thread. ETA: within the hour.

Bloke · 2020-06-08 16:07:53

This particular issue is easy to work around as I mentioned in a previous post. Just return the posted + time zone value directly. The only time that wouldn’t work is if somebody used %s as part of a wider format string, e.g.:

<txp:posted format="%s (%F %T)" />

Can’t see anybody doing that, but to guard against that, it might be prudent to just do a str_replace() of ‘%s’ for the time+timezone, so it never passes %s through the strftime() function. I can’t see any downside to doing that and if it is a PHP bug, we won’t care when they fix it as we won’t be using that feature anyway.

gaekwad · 2020-06-08 16:08:14

Actually, PHP 7.3 is already latest – release-demo now on PHP 7.3.18

Last edited by gaekwad (2020-06-08 16:08:25)

Bloke · 2020-06-08 16:13:47

Even more bizarre:

dmp('DIRECT', strftime('%s', '1591628404'));
dmp('GM DIRECT', gmstrftime('%s', '1591628404'));

Expected:
DIRECT 1591628404
GM DIRECT 1591628404

Actual:
DIRECT -1
GM DIRECT 1591628404

?!!?!?!?!?

So if you add the gmt attribute to your <txp:posted /> tag, it works fine.

Bloke · 2020-06-08 16:20:00

gaekwad wrote #323648:

Actually, PHP 7.3 is already latest – release-demo now on PHP 7.3.18

In which case, short of heavy caching getting in the way, this issue occurs on PHP 7.3 as well?!

EDIT: but on my DO droplet running PHP 7.3.18-1+ubuntu16.04.1+deb.sury.org+1, it returns correct values. No -1 in sight. *head scratch*

Look at the source of the release-demo welcome article and search it for ‘posted’ to see the debug output. The RESULT is what is returned from the various function calls. Text in ALL CAPS indicates what’s being tested.

Last edited by Bloke (2020-06-08 16:26:13)

Bloke · 2020-06-08 16:34:44

So is it an environment thing?

Demo server:

Textpattern version: 4.8.1 (8e4e0ea0982f48cbe19bbb00c4c260a2)
Last update: 2020-06-08 15:00:02
Textpattern path: __TXP-ROOT/textpattern
Article URL pattern: section_title
Production status: testing
Temporary directory path: __TXP-ROOT/textpattern/tmp
PHP version: 7.3.18
GD Graphics Library: bundled (2.1.0 compatible); Supported formats: GIF, JPEG, PNG, WebP.
Server timezone: Europe/Amsterdam
Server local time: 2020-06-08 18:26:26
Daylight Saving Time enabled?: 1
Automatically adjust Daylight Saving Time setting?: 1
Time zone (GMT offset in seconds): Europe/Paris (3600)
MySQL: 8.0.19-10 (Percona Server (GPL), Release '10', Revision 'f446c04') 
Database server time: 2020-06-08 16:26:26
Database server time offset: 0 s
Database server timezone: SYSTEM
Database session timezone: SYSTEM
Locale: fr_FR.UTF-8
Site / Admin language: fr / en
Web server: nginx/1.19.0
PHP server API: fpm-fcgi
RFC 2616 headers: 0
Server OS: Linux 5.4.0-33-generic
Admin-side theme: hive 4.8.1

My server:

Textpattern version: 4.9.0-dev (f5e70ae8fabc5a077d0c84ae2a578ea1)
Last update: 2020-05-31 13:50:37/2020-05-31 01:05:29
Textpattern path: __TXP-ROOT/textpattern
Article URL pattern: section_title
Production status: debug
Temporary directory path: __TXP-ROOT/textpattern/tmp
PHP version: 7.3.18-1+ubuntu16.04.1+deb.sury.org+1
GD Graphics Library: 2.3.0; Supported formats: GIF, JPEG, PNG, WebP.
Server timezone: Europe/London
Server local time: 2020-06-08 17:25:12
Daylight Saving Time enabled?: 0
Automatically adjust Daylight Saving Time setting?: 0
Time zone (GMT offset in seconds): Europe/Berlin (+7200)
MySQL: 5.6.47-87.0 (Percona Server (GPL), Release 87.0, Revision 9ad342b) 
Database server time: 2020-06-08 17:25:12
Database server time offset: 1 s
Database server timezone: SYSTEM
Database session timezone: SYSTEM
Locale: C
Site / Admin language: en / en
Web server: Apache/2.4.18 (Ubuntu)
Apache version: Apache/2.4.18 (Ubuntu)
PHP server API: apache2handler
RFC 2616 headers: 
Server OS: Linux 4.4.0-179-generic
Admin-side theme: hiveneutral 4.8.1

It’s not DST as I’ve tinkered with those and got the same output.
What’s Database server time offset: 1 s? The demo server reports 0 s.

gaekwad · 2020-06-08 16:42:35

Bloke wrote #323652:

So is it an environment thing?

You’re on MySQL 5.6, demo server is 8.0 – I can spin up a fresh server minus MySQL for comparison, any good?

Bloke · 2020-06-08 17:17:54

gaekwad wrote #323653:

You’re on MySQL 5.6, demo server is 8.0 – I can spin up a fresh server minus MySQL for comparison, any good?

Yeah, maybe, thank you. I just can’t figure why MySQL would even be a factor. In the tests, we’re calling a PHP function directly and it’s misbehaving. Now, sure, Txp might be getting in the way in an earlier part of the process so we’d have to eliminate that. That’s easy at the command line:

php -r "echo strftime('%s', '1591628404');"

If that returns -1, it’s PHP or the way it’s built (missing module, something? We’d have to compare a few phpinfo() stacks in various working and non-working environments). If not, it’s something else.

Bloke · 2020-06-08 17:18:46

In fact, duh.Just tested that line on the demo server command line:

-1.

It’s PHP. So we need to start comparing environments. Where do we start?

Textpattern CMS

Textpattern CMS support forum

#13 2020-06-08 15:49:41

Re: strftime unix %s doesn't works on localhost

#14 2020-06-08 15:54:36

Re: strftime unix %s doesn't works on localhost

#15 2020-06-08 16:00:08

Re: strftime unix %s doesn't works on localhost

gaekwad wrote #323643:

#16 2020-06-08 16:04:53

Re: strftime unix %s doesn't works on localhost

Bloke wrote #323644:

#17 2020-06-08 16:07:53

Re: strftime unix %s doesn't works on localhost

#18 2020-06-08 16:08:14

Re: strftime unix %s doesn't works on localhost

#19 2020-06-08 16:13:47

Re: strftime unix %s doesn't works on localhost

#20 2020-06-08 16:20:00

Re: strftime unix %s doesn't works on localhost

gaekwad wrote #323648:

#21 2020-06-08 16:34:44

Re: strftime unix %s doesn't works on localhost

#22 2020-06-08 16:42:35

Re: strftime unix %s doesn't works on localhost

Bloke wrote #323652:

#23 2020-06-08 17:17:54

Re: strftime unix %s doesn't works on localhost

gaekwad wrote #323653:

#24 2020-06-08 17:18:46

Re: strftime unix %s doesn't works on localhost

Board footer