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
Applies To: Extension
Component: TablePlugin
Reported By: MichaelDaum
Waiting For:
Last Change By: KennethLavrsen
... if there is a 01 Jan 1970 in the column.


Desired order DateSorted descending
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/     (revision 785)
+++ lib/Foswiki/Plugins/TablePlugin/     (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

ItemTemplate edit

Summary TablePlugin does not recognize 01 Jan 1970 (epoch 0) as a date
ReportedBy MichaelDaum
Codebase 1.0.9, trunk
SVN Range
AppliesTo Extension
Component TablePlugin
Priority Normal
CurrentState Closed
Checkins distro:d4763d6984f7
TargetRelease minor
ReleasedIn 1.1.0
Topic revision: r8 - 04 Oct 2010, KennethLavrsen
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy