
No PHP required (not absolutely, at any rate)!
In case you decide to follow it up anyway:
In MODx ’widgets’ means the output controls for template variables [TVs] (I’m assuming showdate is one). Info at
http://sottwell.com/how-template-variables-work.html is more up to date than the main site’s documentation. In the definition of your template variable, you can select ’unixtime’ as the widget, and the data associated with the TV will be translated from most standard date formats, such as 2009-06-14 or 14 Jun 09 or Jun 14 2009, into a Unix timestamp, (a few seconds less than*) the number of seconds elapsed since 1st January 1970. So if your template variable contains a recognizable date format, and has the unixtime widget, it will be returned as a Unix timestamp. If it’s the value for Ditto’s dateSource parameter, Ditto will display it instead of the [+date+] placeholder, using the specified dateFormat (’%d-%b-%y resulting in 14-Jun-09, for example).
If the date is stored in a format that isn’t recognized, or if no widget is set for a value that isn’t stored in the DB as a timestamp, or a date formatting widget is set in the TV, the PHP function
strtotime() that is almost certainly involved behind the scenes will return false or -1, depending on your version of PHP. Either way, that will produce a [+date+] of 1 Jan 1970.
Ditto has an excellent debugging console - just add &debug=`1` to your snippet call, and your output will be prefaced by a link to the debug console showing exactly what data is being fed to it. You’ll be able to see whether the problems with your date source are on the input or the output side, and chase the bug from there.
I’m not a great expert on MODx, PHP or Ditto - the above is part of a painful learning process over the past couple of weeks while I’ve been working on an events calendar. Once you do pin down the problems, it’s amazing how flexibly you can use the framework and the snippet.
KP
(*cos they didn’t allow for leap seconds)