Eric Stadtherr wrote:

Date: Tue, 21 Oct 2008 00:13:54 0600

Notice that the time zone offset specifier is missing the "+/-" prefix. Thunderbird seems to drop the zone offset in this case and assume it's a local date. RoundCube, on the other hand, passes it into PHP's handy "strtotime" function which interprets 0600 as the year. This leads at the very least to display problems (in the message list and the message display), and worst case to invalid dates in the database if caching is enabled.

I'd like to make RoundCube a little more tolerant, so I was wondering what everyone else thought about possible solutions. The options I'm considering are:

1. Parse the date using a fixed format string (e.g. "D, d M Y H:i:s O") and one of PHP's other date functions. This would prevent misinterpretation but might be even less tolerant.
2. Analyze the string before passing to strtotime() to identify and work around known issues (of which there would be exactly one at this point). This is a single special case kind of solution, but strtotime might be reliable enough that this is the only case we'll hit.

So, now we have (function format_date()):

while (($ts = @strtotime($date))===false)

I think it will be enough to change that to:

while (($ts = @strtotime($date))===false || $ts < 0)

Time zone offset will be lost. 0 here is for 1970-01-01, to be more strict such value could be greater ;) As you see there's one work around yet in function format_date():

if (is_numeric($date)) $ts = $date;

so, we can add another one for your issue.

ps. isn't it a bug in strtotime?

On Fri, 24 Oct 2008 08:38:17 +0200, "A.L.E.C" alec@alec.pl wrote:

Eric Stadtherr wrote:

...

Date: Tue, 21 Oct 2008 00:13:54 0600

Notice that the time zone offset specifier is missing the "+/-" prefix. Thunderbird seems to drop the zone offset in this case and assume it's a local date. RoundCube, on the other hand, passes it into PHP's handy "strtotime" function which interprets 0600 as the year. This leads at the very least to display problems (in the message list and the message display), and worst case to invalid dates in the database if caching is enabled.

I'd like to make RoundCube a little more tolerant, so I was wondering what everyone else thought about possible solutions. The options I'm considering are:

1. Parse the date using a fixed format string (e.g. "D, d M Y H:i:s O") and one of PHP's other date functions. This would prevent misinterpretation but might be even less tolerant.
2. Analyze the string before passing to strtotime() to identify and work around known issues (of which there would be exactly one at this point). This is a single special case kind of solution, but strtotime might be reliable enough that this is the only case we'll hit.

So, now we have (function format_date()):

while (($ts = @strtotime($date))===false)

I think it will be enough to change that to:

while (($ts = @strtotime($date))===false || $ts < 0)

Time zone offset will be lost. 0 here is for 1970-01-01, to be more strict such value could be greater ;) As you see there's one work around yet in function format_date():

if (is_numeric($date)) $ts = $date;

so, we can add another one for your issue.

ps. isn't it a bug in strtotime?

I don't know that we can call it a bug, since it's actually working as advertised. The documentation says that a 4-digit number that appears after other non-4-digit numbers (e.g. days and months) will be interpreted as a year. So, I'm guessing it reads the 2008 as the year, but then sees the 0600 and happily interprets that as a year. That seems wrong, but consistent with the documentation.

That workaround sounds reasonable, and should match Thunderbird's parsing. I'll test it out and commit if it looks good.