Item8395: TablePlugin does not recognize 01 Jan 1970 (epoch 0) as a date

... if there is a 01 Jan 1970 in the column.

Test

Desired order	Date
1	27 Feb 2008
2	01 Aug 2007
3	01 Jan 1970

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

Commenting is disabled while not logged in