Item8395: TablePlugin does not recognize 01 Jan 1970 (epoch 0) as a date
Priority: Normal
Current State: Closed
Released In: 1.1.0
Target Release: minor
... if there is a 01 Jan 1970 in the column.
Test
The desired order column should be 1-2-3 not 1-3-2.
This is a shortcoming of
Foswiki::Time::parseTime()
that is actually documented in the code. The used Time libraries correctly return a
0
... which is also returned in case of a parse error.
Fixing this might have not foreseeable consequences on anything calling
parseTime()
. I can't see a workaround for
TablePlugin's
_convertToNumberAndDate()
either. Anybody got a
lean solution/hack?
--
MichaelDaum - 20 Jan 2010
Realizing that the problem of having 01 Jan 1970 in a table of dates is extremely rare maybe lean enough to either ignore is. Or to accept that a fix in the core code does not have to work with a 01 Jan 1970 date. ie it is acceptable if
TablePlugin cannot sort the dates if this is one of the dates.
I will update the title so we do not leave an impression that the plugin is total toast.
For 1.1 we need the core code changed so you can see a difference between epoch 0 and failed. And then adjust the extensions that depend on it for this. There are not that many. And noone will run with old plugin on new Foswiki.
--
KennethLavrsen - 20 Jan 2010
How about this patch (not checked unit tests):
--- lib/Foswiki/Plugins/TablePlugin/Core.pm (revision 785)
+++ lib/Foswiki/Plugins/TablePlugin/Core.pm (revision 784)
@@ -519,12 +519,11 @@
try {
$date = Foswiki::Time::parseTime($text);
} catch Error::Simple with {
- $date = $num = undef;
# nope, wasn't a date
};
}
- unless (defined $date) {
+ unless ($date) {
$date = undef;
if ( $text =~ /^\s*(-?[0-9]+)(\.[0-9]+)?/ ) {
# for example for attachment sizes: 1.1 K
--
MichaelDaum - 20 Jan 2010
This bug really is getting annoying. The above patch breaks sorting all together. So, either I can't sort columns with a 01 Jan 1970 date in it or sorting breaks all together because every non-numeric-non-date column is detected as of type date. There's no reliable way to tell if a string is a date or not.
I've just seen that
parseTime()
does indeed return undef on a failure. That's good news we get this bug resolved finally.
--
MichaelDaum - 10 Feb 2010
I can reproduce this bug on 1.0.9 but not on trunk. I presume the changes to
parseTime()
have fixed the problem. Regardless of why it is fixed, I have added a unit test and am setting this to "waiting for release"
--
MichaelTempest - 03 Jul 2010
Was fixed in
Item2043.
--
AndrewJones - 03 Jul 2010