Item11290: JSCalendar mangles date fields unless format is iso or dd mmm YYYY

I couldn't find if this is a duplicate. When we now edit a topic formfield of type date the value goes to 1 Jan 1970. This is bad, of course. We have used %d.%m.%y as date format, e.g. 31.10.2011 but now that's not possible to set with JSCalendarContrib. I see also configure's DefaultDateFormat is a select without our format. JSCC barfs when I try to set format %d.%m.%Y.

Babar mentioned on IRC it was known, because it don't understand the format and then defaults to epoch. Sorry if I misinterpreted.

-- LarsEik - 25 Nov 2011

The JSCC barf was when I tried to set JSCC language to 'no' or 'nb' for norwegian. We don't need that so I have it de default.

When date format is default every edit will replace any saved date with '1 Jan 1970' and that will be saved. Many edits are for just one other field and we might not even notice that date fields get screwed.

We have used and prefer date format day.month.year, like %d.%m.%Y which should display as 31.10.2011. When I set this format in JSCC dateformat in configure and we edit the date field shows the text %d.%m.%Y and the days in the calendar shows NaN and the calendar header is undefined, NaN

-- LarsEik - 25 Nov 2011

I suspect this applies to Release01x01 - changed release target accordingly

-- PaulHarvey - 25 Nov 2011

I've added tests for %d.%m.%Y to the unit tests and they all seem to be formatted correct. I suspect that it's an issue with the javascript piece. ... confirmed. The issue is in the javascript component. Note that this particular calendar widget - www.dynarch.com/projects/calendar - has been replaced by a non-free version and is no longer maintained. I wonder if it would be better to switch over to the JQuery UI::Datepicker widget - but not sure how to do that.

• This is still the most feature rich date picker. And other date pickers lack a time component. -- ArthurClemens - 28 Nov 2011

-- GeorgeClark - 28 Nov 2011

Arthur, have we changed the range of supported date formats for JSCalendar/date formfields?

Lars, did this used to work? Is this a new problem?

Fundamentally the issue seems to be that the new foswikiDate code ignores the configured date format and tries to parse it without that knowledge

Changed the title of the bug to reflect the underlying cause of the problem

-- PaulHarvey - 28 Nov 2011

JSCalendarContrib does not read {DefaultDateFormat} as Lars mentioned. This could be changed by changing $Foswiki::cfg{JSCalendarContrib}{format} = '%e %b %Y' to $Foswiki::cfg{JSCalendarContrib}{format} = '$Foswiki::cfg{DefaultDateFormat}'.

Note: to get the date string 28.11.2011 you need to use uppercase Y.

When the date format is set to %d.%m.%Y, nothing strange happens when the field is empty. The date can be selected and is stored in that format in the field.

When the field does have a value, the field gets rendered. Date.pm calls Foswiki::Contrib::JSCalendarContrib::formatDate and gets the 1970 date.

formatDate calls Foswiki::Time::parseTime to get the epoch seconds and since parseTime does not understand 28.11.2011 it returns nothing.

So currently there is no conversion between the JSCalendarContrib format and the formats that Foswiki::Time::parseTime understands.

The output format is translated though: foswikiDateFormat gets the value $day.$mo.$year. So these tokens need to get their value and then fed to parseTime in the right order.

-- ArthurClemens - 28 Nov 2011

Confirmed and URGENT for 1.1.4. Reverting to 1.1.3 and the date formats are fully functional. JSCalendarContrib manages to decode the stored dates in Meta regardless of numeric or written month, and saves into the requested $Foswiki::cfg{JSCalendarContrib}{format}. With initial tests, it appears acceptable to change formats without loosing data.

This needs to be fixed or reverted prior to release of 1.1.4. The 1.1.3 (11 Apr 2011) version of the plugin works fine on 1.1.3.

-- GeorgeClark - 28 Nov 2011

Also confirmed. The 1.1.3 version of the plugin works fine on 1.1.4, including support for on-the-fly changes to the date format. %d.%m.%y works fine. Migrating between formats (Meta containing dd Mmmmm YYYY, format=%d.%m.%y - clean as well.

We need a solid fix for this or we need to revert. Also the released Extension needs to be reverted. Release only to Extensions/Testing until fixed.

-- GeorgeClark - 28 Nov 2011

Looks like there are more troubles here.

StaticMethod formatDate( $foswikiDateStr, $jsCalendarFormat  ) -> $formattedDate

This routine prepares the date for processing by Foswiki, but it parses the dated using Foswiki::Time before trying to decode the jsCalendarFormat. So if Foswiki doesn't understand the format, it changes $epoch to 0, and forces the date to 1/1/1970.

-- GeorgeClark - 29 Nov 2011

Here are the changes I've made that seem to have everything working again - but probably way too much risk for 1.1.4

• Added datejs to the script libraries - http://www.datejs.com/
• Changed foswikiDate.js to simply return Date.parse(dateString); - using the replacement date parse routine provided by datejs.
• removed the call to renderDateForEdit Foswiki::Contrib::JSCalendarContrib::formatDate in Date.pm - just let the field contents pass through to the javascript code.

Results: Alternate formats work, including the requested %d.%m.%y And "clever dates" can be entered into the date field - ex: "next Wednesday" and the date picker will jump to that date. Need to pass the input through the picker to save the parsed results back into the field.

If we went ahead to use this library - need to localize it - including the appropriate locale specific parse routine - ex. date-de-DE.js

-- GeorgeClark - 29 Nov 2011

So we reverted changes from Foswikitask:Item11020. An improvement in frontend date handling is to include date.js. But that need would go away if date fields were ISO dates in the first place (and frontend display would need to be done by perl code anyway). See discussion at ConvertDatesToISO.

For now pushed to 1.1.5.

-- ArthurClemens - 29 Nov 2011

Arthur, I'm going to push it to 1.2, since that will be the trunk release, and all the changes are still there. This gets it off the 1.1.4 release blockers list. We can always back-port to 1.1.5 if we get a workable solution.

-- GeorgeClark - 30 Nov 2011

We cannot edit date fields anymore, except as plain text. First the calendar icon started to do a direct 'save' instead of popping up the calendar and after more updates now the calendar icon is gone. Configure also says jquery version chosen is missing, i.e. jquery-1.7 or 1.7.1. Might be separate issue from this but I cannot verify anything as it is now.

-- LarsEik - 19 Dec 2011

That looks like a js error. What do you see in the error console?

-- ArthurClemens - 19 Dec 2011

I get two 404 (not found): JSCalendarContrib/calendar.js and calendar-large.css.

When updating I do the following from svn root:
# find -L -type l -exec rm {} \; and
for f in $(ls -d */);do cd $f;svn cleanup;svn up;cd..;done

chown -R www-data:www-data /path/to/foswiki

/etc/init.d/apache2 force-reload

I have mod_exires enabled and set to 1 day.

-- LarsEik - 19 Dec 2011

reinstalling jscc fixed the missing files.

-- LarsEik - 19 Dec 2011

Can I close the task then?

-- ArthurClemens - 19 Dec 2011

I had to do a svn status also to remove generated files from pseudo-install. Still there is a problem when editing with an edit template using %RENDERFOREDIT. Empty fields then gets 1970. That does not happen without the edit template, then it stays empty just as it should. Could that be a problem with FlexFormPlugin?

Now when setting JSCC format to $Foswiki::cfg{DefaultDateFormat} then I cannot actually get the selected date from the calendar. Error console gives: =Uncaught TypeError: Cannot read property 'length' of null calendar.js:1815=

What seem to work best is using iso date as foswiki default (yyy-mm-dd) and set JSCC format to %Y-%m-%d. It's annoying to get 1970 as defaults but it's a minor.

-- LarsEik - 20 Dec 2011

Commenting is disabled while not logged in