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?
--
Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252
LAN Management System Developer http://lms.org.pl
Roundcube Webmail Project Developer http://roundcube.net
_______________________________________________
List info: http://lists.roundcube.net/dev/
