Item11195: Date form field decrements by one day on every page save

We've had great luck with data forms on our wiki but are running into a problem where every time we edit and save a page with a form attached, the date decrements by one day. This includes dates set currently, in the future, and ones that had defaulted to a 1969 date when it isn't set explicitly. It may have cropped up after the 1.1.3 update but I can't say for sure. If there are multiple dates in a form, it affects all of them the same way. I couldn't find any reference to this happening anywhere else and am at a loss for further troubleshooting. Any suggestions?

Thanks.

-- JohnV - 21 Oct 2011

Known issue, very likely, http://foswiki.org/Tasks/Item10714. Try with the fixed javascript attached there.

-- LarsEik - 23 Oct 2011

Thanks for the suggestion. I replaced the 3 files per the task above without luck. At the moment, clicking edit resets all dates on the page to 31 Dec 1969, rather than just going down by a day as had previously been the case. I reverted back to the original 1.1.3 files for that directory and am still getting the 1969 behavior so I'm not sure when that started.

Tried from different browsers, cleared caches, etc. Are the .js files are being cached somewhere else that I need to clear?

-- JohnV - 24 Oct 2011

Raising to urgent... I thought we'd fixed this.

• Are you running latest JSCalendarContrib ?
• under bin/configure, what are your {DefaultDateFormat} and {DisplayTimeValues} values? (found under Internationalisation -> Locale)
• What is your server's timezone?
• Did you see any errors in your browser's error/javascript console?

We're about to release Foswiki 1.1.4, so your feedback would be very welcome

-- PaulHarvey - 24 Oct 2011

JSCalendarContrib is 1.4.1 and I've been attempting to keep the extensions up to date in the hope that one of them would have fixed the problem. I'm pretty sure the issue didn't appear directly with the 1.1.3 update, though can't recall for sure. The issue of 31 Dec 1969 showing up in previously unset fields started at some point in the summer though.

$Foswiki::cfg{DisplayTimeValues} = 'servertime';
$Foswiki::cfg{DefaultDateFormat} = '$day $month $year';

Server timezone is America/Los_Angeles and I haven't seen any other time/date related issues with any other applications that are hosted on the same system.

On the Javascript error console, I only get this when clicking edit on a page with a form with a date field.

[19:04:04.243] Use of getAttributeNode() is deprecated. Use getAttribute() instead.

I did put the newer foswiki_edit files in place for the last tests. Just to clarify further, it appears as if the current behavior when editing pages with date form fields is for 31 Dec 1969 to appear in fields that were previously blank, and any that were existing get decremented by a day. Primary testing has been with Firefox 7.0.1 on OS X 10.6.8. Identical behavior with Safari 5.1.1.

-- JohnV - 25 Oct 2011

Ok. I tested with Chrome 14 on foswiki.org and couldn't reproduce.

I won't have time to spend on this till the weekend. But I have a few more questions:

• What is the value of your {JSCalendarContrib}{format} setting?
• Are the 1969 fields truly blank (empty string of length zero) - or do they contain spaces? You can use ?raw=debug to check, Eg. Item11195 (check the META:FIELD datum's value key - should look like value="" )

Need to set up a VM running a Foswiki configured as closely to yours as possible. An anonymized copy of your LocalSite.cfg would be useful.

Here's a little patch to help with the 1969 problem, but it won't help with the decrementing.

diff --git a/lib/Foswiki/Contrib/JSCalendarContrib.pm b/lib/Foswiki/Contrib/JSCalendarContrib.pm
index 464e765..674b2e6 100644
--- a/lib/Foswiki/Contrib/JSCalendarContrib.pm
+++ b/lib/Foswiki/Contrib/JSCalendarContrib.pm
@@ -285,7 +285,7 @@ sub formatDate {
 
     # do not format if the field value is empty
     # so we won't prefill the field with a 1970 date
-    return '' if !$foswikiDateStr;
+    return '' unless ($foswikiDateStr and $foswikiDateStr =~ /\d/);
     
     my $epoch = ($foswikiDateStr =~ /^\d+$/)?$foswikiDateStr:Foswiki::Time::parseTime($foswikiDateStr
     $epoch ||= 0;    # otherwise we have to work with an empty string

-- PaulHarvey - 25 Oct 2011

You may also wish to try downgrading to a previous version of JSCalendar by choosing an old tarball from http://foswiki.org/bin/attach/Extensions/JSCalendarContrib?filename=JSCalendarContrib.tgz;revInfo=1

-- PaulHarvey - 25 Oct 2011

I've attached my LocalSite.cfg and will have to get back to you on the other items this evening. Am I supposed to be clearing the browser cache between tests? Just want to make sure I'm getting everyone clean data...

-- JohnV - 25 Oct 2011

Pre-edit of a form w/o an existing value: %META:FIELD{name="PurchaseDate" attributes="" title="Purchase Date" value=""}%

Post-edit: %META:FIELD{name="PurchaseDate" attributes="" title="Purchase Date" value="31 Dec 1969"}%

I may be completely missing something, but my /var/www/Foswiki-1.1.3/lib/Foswiki/Contrib/JSCalendarContrib.pm doesn't accept that patch and I can't find the text referenced anywhere in that file. I've attached it as well. Looking at the download link above I see that we're 7 revs behind the latest for JSCalendarContrib, but the Foswiki configure interface shows what's installed as the latest. Let me know if I should be trying to manually install a newer version.

I didn't downgrade to an earlier JSCalendar release since we're used to just living with the problem, but would be glad to do so if it'll help with the troubleshooting.

---

Ah, I see

We changed to a x.y.z release numbering scheme, rather than 'DD MMM YYYY', so it seems that in this case, the configure interface is confused about the local version being later than the foswiki.org version.

Could you please try choosing "re-install" ? That should fetch & install the current package from foswiki.org, and resolve the problem.

-- PaulHarvey - 26 Oct 2011

Ok, so I ran a re-install, and it appeared to download and install something. In the extensions configure window both the Installed Release and Most Recent Release reference 1.4.1. Of course I can't recall exactly what it said before, but I think the two items were different, even though it said it was at the latest release.

The new JSCalendarContrib.pm is dated Sept 6 2011 and does contain the text you referenced in the patch above. I applied the patch and now it appears as if the current behavior is for date fields not populated, to remain empty upon page edit, but existing date fields with values get changed to 31 Dec 1969. This was a quick test on Firefox and Safari.

I'll test more extensively this evening. Thanks for the help on this!

-- JohnV - 26 Oct 2011

Best to check carefully your list of installed plugins in configure. Looks like there is a bug in the dependency check that fails to flag a x.x.x version as newer than a dated version. (Test was backwards.) If you see an installed version as a date, and a available version as a dotted release, then dotted release is most likely newer. I don't think anyone is converting back to date based releases.

-- GeorgeClark - 26 Oct 2011

JohnV, can you re-install again - basically undo the patch - I'm 99% sure the patch shouldn't be necessary

-- PaulHarvey - 27 Oct 2011

I did an un-install on JSCalendarContrib and then did an install and it's showing 1.4.1 as the installed version and the files on disk are dated Sept 6 2011 which appears to be the latest rev based on the link Paul had referenced.

After clearing browser caches (do I need to be doing that?), I tested again with FF and Safari on OS X and the current behavior is to reset existing date fields to 31 Dec 1969 but to leave unset fields empty. On Firefox I get the same JS error:

Use of getAttributeNode() is deprecated. Use getAttribute() instead. 

There was a bunch more stuff in the Safari error log, but looked totally different so I wasn't sure if it was all relevant.

-- JohnV - 27 Oct 2011

Thanks for all this testing, John. I think we've got the info we need - we just need to reproduce.

-- PaulHarvey - 31 Oct 2011

FWIW the getAttributeNode error is likely coming from TinyMCE or jQuery - which makes me wonder if this problem persists in raw edit mode

-- PaulHarvey - 31 Oct 2011

I'm trying to recreate this on Foswiki 1.1.4 svn checkout. I'm not having any luck.

• Created a TestTopicForm with a two-entry form:

Name	Type	Size
ItemName	text	80
ItemDate	date	30

• Created a TestTopic and attached the form. Picked "Today's date" - the default.

Multiple iterations of save, both raw and TMCE, and the date remains on today's date.

AH... Got it - Setting the $Foswiki::cfg{DisplayTimeValues} = 'servertime';- and the date starts decrementing. The raw meta contains the correct date, but the displayed date is decremented by 1. Save then saves the decremented date.

-- GeorgeClark - 15 Nov 2011

JohnV, If you want to apply the fix early, the change is in distro:6d6895e1952c (If you get a failure retry it a couple of times - trac is being uncooperative today)

-- GeorgeClark - 15 Nov 2011

Note this issue was introduced in a post 1.1.3 version of JSCalendarContrib. Will release this extension directly to get the fix prior to 1.1.4.

-- GeorgeClark - 15 Nov 2011

Uploaded Release 1.4.2 of JSCalendarContrib.

-- GeorgeClark - 15 Nov 2011

Ok, I manually swapped in the newer JSCalendarContrib.pm file and so far it is looking good. I've loaded multiple form based pages in in both the WYSIWYG and text editors and dates are staying at what they were set at. Date fields that weren't previously set are also still behaving and remaining empty so I think all is well.

Thanks for your help on this and keep up the excellent work!

-- JohnV - 17 Nov 2011

Sorry, have to re-open this, as George's fix triggers a fix by me of the unit tests + some core, which triggered another round of fixing. Now all this mess should be sorted out. Unit tests are pretty thorough, but John, it would be great if you could try the latest Foswiki/Time.pm alongside your latest JSCalendarContrib.pm, and let us know if I haven't broken anything.

Thanks a lot!

-- OlivierRaginel - 19 Nov 2011

Yes, I'd be glad to test some more. Can you tell me where to find Time.pm? I looked around on trac and couldn't find it.

-- JohnV - 21 Nov 2011

Try http://trac.foswiki.org/export/13134/branches/Release01x01/core/lib/Foswiki/Time.pm

-- GeorgeClark - 21 Nov 2011

I swapped in the Time.pm file for my existing one in lib/Foswiki and the date values are behaving correctly on edits. Values are not getting changed when the page is loaded for editing and empty date fields still stay empty. Multiple edit/save cycles tried. Seems like the identical, correct behavior still but let me know if I should be trying something specific instead.

-- JohnV - 21 Nov 2011

Excellent, Thanks JohnV

-- GeorgeClark - 22 Nov 2011

Commenting is disabled while not logged in