Strange behavior: Date TV with Unixtime

375 Posts

FuryDE Reply #1, 17 years, 2 months ago

Hello,

I am running a webiste with some events stored in it. Among others, the events have two TVs [tt]eventStart[/tt] and [tt]eventEnd[/tt]. Both were initially set as input type [tt]Date[/tt] and ouput [tt]Date formatter[/tt] (with standard values).

All works fine up to here.

In the database, the date values are stored as "readable" strings, i.e. "27-08-2009 10:33:00" for now. The format may result from the language setting in the manager, it is german. It is the same format like in the input fields in the manager.

Meanwhile I have changed the output to [tt]Unixtime[/tt]. I adjusted my few own snippets so that they work with Unixtime values. The values in the database were not changed by this change.

But when I now create a new event and set a date for [tt]eventStart[/tt], the resulting Unixtime value is wrong. In the database I can read the correct date value (exactly as I picked it with the date selector). The format in the database is exatcly the same as for the "old" events. But when I (i.e. my snippets or Ditto) now retrieve the TV value as Unixtime, the resulting value is completely wrong. The date is in the year 2022 (instead of 2009). In detail: I picked 2009-10-16 8:15:00 but the Unixtime value represents the date 2022-04-01. When I go to edit the event, I can see the correct date that I had picked before.

I have no explanation for this behavior.

My big, big problem is: Shortly after I had changed the output from Date formatter to Unixtime, I updated the complete MODx Manager from 0.9.6 to 1.0.0. And I don’t know, if the problem already existed in 0.9.6, because I didn’t create new events in the meantime.

As always, any ideas of this great community are very much appreciated

Thank you
Martin

928 Posts

kp52 Reply #2, 17 years, 2 months ago

The code for the unixtime widget in manager/includes/tmplvars.format.inc.php reads:

case "unixtime":
				$value = parseInput($value);
				// Check for MySQL style date - Adam Crownoble 8/3/2005
				$date_match = '/^([0-9]{2})-([0-9]{2})-([0-9]{4})\ ([0-9]{2}):([0-9]{2}):([0-9]{2})$/';
				$matches= array();
				if(strpos($value,'-')!==false && preg_match($date_match, $value, $matches)) {
					$timestamp = mktime($matches[4], $matches[5], $matches[6], $matches[2], $matches[1], $matches[3]);
				}
				else { // If it's not a MySQL style date, then use strtotime to figure out the date
					$timestamp = strtotime($value);
				}
				$o = $timestamp;
				break;

Your date format matches the regular expression, so your dates are being fed (in the wrong order) into the mktime() function. mktime(8,15,0,10,2009,16) does indeed produce a timestamp for 2022-04-01 08:15:00.

I’m pretty sure that MySQL format for dates is actually YYYY-MM-DD, not DD-MM-YYYY that this function seems to be looking for.

Meanwhile, good old strtotime() handles your date format correctly (in PHP 5.2.9-2). You could consider simplifying the function (lines 233-245 in MODx 1.0) so the widget always uses strtotime(). And I could consider putting in a bug report, if my recollection of MySQL dates is correct.
cool

KP

375 Posts

FuryDE Reply #3, 17 years, 2 months ago

Thank you, this might be the problem. But what I still don’t understand then:

Why does it work correctly with the old events but not with the new ones. The data in the MySQL database look the same (using phpMyAdmin) and the database field is just a string, not a date field.

An event that I created some days ago with the same value for eventStart as posted above results in the correct date and time. But the newly added events don’t sad

Thank you very much
Martin

375 Posts

FuryDE Reply #4, 17 years, 2 months ago

Just for info: it seems to be working now. What have I done?

I configured the server to use PHP 5 instead of PHP 4. Yes, shame on me. Thanks for your help all the more. I know that Evolution wants to have PHP 5, and I didn’t suspect the server to use the old version. I don’t know how I could miss it while upgrading. Well, there the MySQL version is checked, but not PHP, is it?

Greetings
Martin