Datetimeobj class buggy about symphonycms

[brendo]

The first is a Date/Time issue, not core. However, I have made a change to the General::createXMLDateObject to accept a Date and Time format. What this means is the the output can be given the Symphony Date constants (which are read from your config) to get the result you desire.

I don't want to push the Date field to use these constants in 2.2.2 as potentially it will break sites that are relying on the current functionality. There is also the very real possibility that your configuration settings work well for the frontend, but not the backend. Consider this example, my testing build uses H:i a for time, which makes 2:00 pm. If the Date field used this on the frontend, it becomes a pain in the ass to incorporate with XSLT. So we might change it so H:i, (which is the current default), but now the backend loses a bit of niceness for the sake of the XSLT.

We should put this on the radar with #693, where we have already started some discussion about different output formats.

Now for the second part, I think this is also related to Date formats, but I not sure how you made the connection with Line 135?

/cc @nilshoerrmann

[nilshoerrmann]

I responded on the forum regarding the first part. I actually don't understand your problem.

Regarding the second issue: what's your PHP version. This should not happen with PHP 5.3+. If it does, this is a PHP issue.

[designermonkey]

I'm using PHP 5.3.2.

If I use any other date format than d/m/Y it works fine, like Y/m/d, it's only happening when I use my desired d/m/Y, which coincidentally is standard British date format.

I narrowed it down to line 135 by trying a date that would break if the day and month were switched, like 23/10/2011, as 10/23/2011 would fail being formatted with d/m/Y.

I'm sorry to disagree with you on this, but this is a bug. DateTimeObj should be able to accept any formatted date. I can understand why it is stored in the DB and therefore the XML as an Americanised date, that is clear to me after some sleep, but swapping the day and month around? That's just wrong.

[nilshoerrmann]

Symphony parses dates using the system date format, see line 116. Line 135 will only be used it the given date could not be parsed using the system date format.

Does your PHP version include DateTime::createFromFormat() (it should if you are on 5.3+).

[designermonkey]

I wouldn't know. How do I find out?

It definitely gets to that line using d/m/Y as the date format.

[nilshoerrmann]

If you add this after line 116, what's the result?

echo __SYM_DATETIME_FORMAT__ . ' / ' . $string;
vardump($date);
die();

[nilshoerrmann]

By the way shouldn't you celebrate something and not debug Symphony :)

[designermonkey]

Hmmm...

d/m/Y H:i / 02/07/2011

boolean false

[nilshoerrmann]

Try replacing line 116 with this:

$date = DateTime::createFromFormat(__SYM_DATETIME_FORMAT__, $string);
if($date === false) {
    $date = DateTime::createFromFormat(__SYM_DATE_FORMAT__, $string);
}

[designermonkey]

The output from that using your post earlier is

d/m/Y / 02/07/2011

object(DateTime)[83]
  public 'date' => string '2011-07-02 10:25:00' (length=19)
  public 'timezone_type' => int 3
  public 'timezone' => string 'Europe/London' (length=13)

Now that's better ;o) That works fine. I don't know what the implications for this are...

[designermonkey]

Taking out the dump also allows that to save correctly, with both the Date Time field ad the core Date field.

[nilshoerrmann]

Just for the records:

This problem resulted from the fact that the given date was in a short format (d/m/Y) while Symphony expected a long date with time (d/m/Y H:i) – so Symphony used the fallback given in line 135. As PHP expect American date formats and a British date format was given, Symphony confused day and month at this stage. To work around this issue we should check short and long system date formats – __SYM_DATETIME_FORMAT__ and __SYM_DATE_FORMAT__ – in line 116 and 121.

[brendo]

@designermonkey, @nilshoerrmann Does the above commits fix this issue for you?

[designermonkey]

Certainly does. Is this in for the next release, or is it going in as a bug fix? I would suggest bugfix.

[brendo]

It'll be in 2.2.2, I'm packaging up Beta 2 tomorrow.

[designermonkey]

Brilliant, cheers @nils and @brendo