Published dates not parsing correctly

I also have a nutty one with dates.

I have a site built in Revo with a large number of resources that where imported from Evo using the amazing Provisioner plugin.

This works from some articles:

1
[[+publishedon:strtotime:date=`%d/%m/%Y`]]


But for some reason older resources (I suspect those imported from Evo) the date comes out as 01/05/9540 or 01/05/0 even after opening the resources chaning the date and resaving.

However this seems to have the opposite effect:

1
[[+publishedon:strftime:date=`%d/%m/%Y`]]


The resources showing incorrect dates now show fine but others so up as 01/01/1970

OK and what is even more odd is that several of page templates have this:
1
[[*publishedon:strtotime:date=`%b %d, %Y`]]


Which seem to consistnetly return the date correctly across all imported Evo docs and new docs.

Using the same call in a chunk to list related pages with the + not * returns a mixed update:

1
[[+publishedon:strtotime:date=`%b %d, %Y`]]


Examples:

Wrong date: Related box in the right hand column of this page: http://www.centreforcities.org/events/2009/09/28/regions-incorporated/
Correct date: http://www.centreforcities.org/research/2006/02/22/cityleadership/

Does this mean the issue could be with the way publishedon is called?

The bug is happening in Revo 2.2.6-pl by the way.

Any ideas why?

Does this mean the issue could be with the way publishedon is called?

Yes, in some cases it may be the raw value of the publishedon field (which is a unix timestamp), in other cases it may be the processed value, which is a date string.

Both of these will return a formatted date string:

From a snippet:


From a tag in the page:


In both cases, if you want a particular format, you need to use strtotime to turn it back into a unix timestamp, then strftime to format it.

If something is returning the raw timestamp, you only need strftime.

To see which you need, you can try it with no output modifiers and see if you get a number or a formatted date.

The first thing to do, though, is look at the modx_site_content table in the DB and see if the publishedon field is always a reasonable number. If there are problems, editing the Resources and setting a reasonable publishedon date (that's different from the original), then saving them should normalize them.

Thanks Bob,

On all pages [[*publishedon]] works fine but the same pages called listed on another page via GetRelated with a tpl chunk that includes [[+publishedon]] returns a unix timestamp in some cases and in other returns a formatted date.

We have tried changing the published dates for resources that are returning a unix timestamp and re-saving the offending articles but this doesn't seem to make any difference.

I suppose the next step would be to stat digging int he database to try and see what is going on in the raw date values.

The 'false' in this line in the getRelated class file makes it get the processed version (not a timestamp):



Maybe somewhere else it's getting the raw value (timestamp).

I suspect that they're all raw timestamps in the DB, but you can get the raw value if you ask for it, which some extra is probably doing.

Welcome to the "I hate dealing with dates in PHP" club.