Hi,

I've recently moved to a new server, and reinstalled my XOOPS site. For some reason, "some" of the themes (which display today's date) are displaying the date incorrectly. The date looks something like this:

Sunday, November 6, 116568

It gets even weirder. Anytime I browse to another page on the site, the date increments or changes to another date (with the same weird format).

Other themes display the date correctly, and there doesn't seem to be a date problem outside of the themes (such as with date/time stamps within the postings of various modules).

The only difference I noticed (regarding themes) is that the date is wrong when the theme uses a smarty date variable (such as:<{$smarty.now|date_format:"%A, %B %e, %Y"}>). The theme that displays the date correctly uses javascript to display today's date.

I've never had this problem with these same themes on my old site (which was on another server). The only differences other than a different server, is that I recently installed the latest versions of "Frameworks" and "Xoopseditors", and I've upgraded from 2.0.15 to 2.0.16. I even tried using an earlier version of Frameworks (which made no difference), even though I didn't think it would influence the themes in any way.

I don't think this is a server issue, since the dates display properly everywhere else. Does anyone have any idea what could be causing this problem?

Dave

Any ideas on this date problem?
(The details are included within the original post above.)

Has anyone else noticed a similar date problem on their site?

More specifically, this date problem is occurring with several of the themes I've initially installed, such as 7Clean, 7dana-rose, and girlsclubII. However, geometric_red displays the date properly.

Again, the only difference in the actual themes is that geometric_red uses a javascript script to generate/display the "correct" date, but the other themes use the following smarty variable: <{$smarty.now|date_format:"%A, %B %e, %Y"}>, which generates the incorrect date and causes other odd behavior (such as the date continuously incrementing while browsing to other pages within the site).

I'm 99 percent sure there is nothing wrong with the actual themes, since the date has worked correctly on other XOOPS sites of mine. However, I don't know where else to look for the source of the problem. Could it be a problem with the latest version of XOOPS (2.0.16)? Could something be corrupted with the Smarty components of XOOPS? Could it be that the latest copies of Frameworks/Xoopseditors are causing some problem? Or could it be some kind of server problem?

Any direction with this would be very much appreciated.

Thanks,
Dave

UPDATE:

Well, from what I've researched, this appears to be a PHP language bug that occurs on 64 bit servers. This explains why I suddenly started receiving this error after I moved on to a new server. Apparently, the error is with the PHP strtotime() function. From what I read, it appears that the smarty tag <{$smarty.now|date_format:"%Y"}> utilizes data from the strtotime() function, which causes this specific smarty tag to fail on 64 bit machines. I tried out the strtotime() function on my server, and it generates the error. Also, the result changes every time I refresh the page, which is consistent with the behavior in the themes.

They are working out (or have worked out) a fix for PHP 5 on 64 bit servers, but I don't know if they are doing the same for PHP 4 (apparently they haven't thus far). Thus, theme developers should be aware of this possible smarty tag problem, and maybe update their themes or provide some replacement code for people experiencing this date error.

It would be good to hear from some other XOOPS users, to confirm that others are having the same problem as me. This may become more of an issue as more web hosts update to 64 bit servers.

Here is a link to an old discussion about the PHP bug.

Dave

If your host offers both PHP4 and PHP5, changing the default PHP version that XOOPS uses to PHP5 will fix the date error. I just tried it out on my Surpass hosting account and it works.

Go to your .htaccess file in your root XOOPS directory, and add the following line:

AddHandler application/x-httpd-php5 .php

Dave

The Smarty date_format modifier uses the function strftime, which converts a timestamp to a date/time string, not the function strtotime, which converts a date/time string to a timestamp.



Maybe this is a different PHP bug?

Hi Dave_L,

From what I read, there was a past controversy over how strtotime was being used. Apparently, the strtotime function was sometimes using a timestamp (time()) as the data input for this function, which works on older systems, but "apparently" produces errors on 64 bit systems. There was a debate over whether a timestamp or time() should or could be interpreted as a date string. The conclusion of the controversy, was that timestamps or time() should not be passed to strtotime, since it causes odd results at times (depending on the host system configuration). The last thing I read was that this issue was resolved in PHP5.

I'm not sure exactly where strtotime factors into the smarty date_format, but from what I researched, it sounded like it had been utilized in some way. Whether this is accurate, I don't know. I'm not a PHP programmer, so I'm just going by what I've read online. I'm wondering if maybe earlier versions of Smarty utilized strtotime in the date function calculations?

In any case, there is definitely a smarty date bug that occurs with PHP4 on some server configurations, and which causes smarty generated dates in XOOPS themes to display incorrectly. I noticed the problem after moving to a new host/server. Switching from PHP4 TO PHP5 solved the problem on my end.

Dave

date_format may not use strtotime, but smarty_make_timestamp() does - and the supplied datestring is run through that to make a timestamp, disregarding that the date may already be a timestamp.

I suggest that this is brought to the attention of the Smarty developers, so they can find a solution in smarty_make_timestamp().

Since the function allows for dates in MySQL format like this: 20061215112300 it is not enough to just check for whether the supplied $string is a number, but perhaps it could check first whether the string is actually a number and in that case, check if it is a MySQL date string and if not, just return the number unharmed.

I don't know if there are potential clashes between MySQL and UNIX timestamps, so that will be the task of the Smarty developers to investigate.

Hi Mithrandir,

Quote:

I checked on the PHP site and Smarty forums, and this issue has been discussed quite a bit by various developers. I found out that strtotime() was rewritten in PHP version 5.1.0. However, I don't know if there have been any significant revisions to the way smarty implements smarty_make_timestamp() (or if it was necessary after modifying strtotime). I saw some vague references to some kind of modifications being made or attempted, but nothing specific.

I assume that the improvements to strtotime() is the sole factor in fixing the issue on my particular server, since it now works correctly after I switched from PHP4 to PHP5. However, I don't know if there could still be a problem on other servers (depending on the system's configuration and how it presents its system time data). Also, if a host does not offer PHP5, then there may be no solution other than changing to a host that offers PHP5(unless you code the date without using Smarty, such as in Javascript).

Dave