Item1187: The date displayed in ActionTrackerPlugin is one day earlier than typed in

The date displayed in ActionTrackerPlugin is one day earlier than typed in

For example:

%ACTION{ created="2009-03-02" creator="Main.KennethLavrsen" due="2010-01-21" state="open" uid="000007" who="Main.KennethLavrsen" }% Test me
- Created by KennethLavrsen, 02 Mar 2009 - 19:46 %ENDACTION%

is displayed with due date 20 Jan 2010.

-- KennethLavrsen - 02 Mar 2009

It works for me. That due date displays as, "Thu, 21 Jan 2010".

-- SeanMorgan - 22 Apr 2009

Works for me too. Possibly some feature of timezones on the platform? I'm in GMT+1

-- CrawfordCurrie - 22 Apr 2009

It does not work for me still even though we are now in Daylight Saving Time.

-- KennethLavrsen - 22 Apr 2009

It works for Sean and Crawford because they live on GMT line or later.

This is the same bug that I fixed in SSP a few days ago. When you have user entered data you must asume that the date people type is the date people want to see. It is wrong to let Foswiki convert from localtime to GMT on user date.

For us in Copenhagen and in Malaysia it meant that all dates were displayed a day early and much worse - each time someone edited an action all the dates in that action was decremented by one day. A total disaster for those trying to use the plugin for anything useful.

Fix is very simple. Just tell Timeparse that the the date in is GMT. Then it does not convert anything. It fits no matter what timezone you are in.

This fix is so important that I will release a new version of ATP now. It must be many that have given up on this otherwise very fine and extremely useful plugin. This plugin is what makes Foswiki (and the old project) stand out from anything else. I would not start enhancing this plugin but I assume fixing such an important bug is OK. Many of my colleagues were extremely happy when I presented the fixed plugin this morning. Projects using ATP that they had given up on were revived right away.

-- KennethLavrsen - 15 May 2009

Broken for me, using 15 May ATP and FW 1.0.4. Things are off by 1 day if I set configure to gmt, 2 days if I set configure to server time (which is US Eastern Daylight Savings, and the server time is correct).

Bummer.

EDIT: Whoa - it decrements 3 days at a time on action edits when locale set to server time, 2 days when set to gmt, and always displays a day earlier than the actual value in the action.

-- AaronFuleki - 09 Jun 2009

If this is true then we have moved the problem from east of Greenwich to West of Greenwich.

I need to try and set a test server as if it was a USA TZ to verify this.

Meanwhile.

The code line that changes the behavior is lib/Foswiki/Plugins/ActionTrackerPlugin/Action.pm

line 55

Change

my %pdopt = ( NO_RELATIVE => 1, DATE_REQUIRED => 1, WHOLE => 1, GMT => 1 );

to

my %pdopt = ( NO_RELATIVE => 1, DATE_REQUIRED => 1, WHOLE => 1 );

and you are back to before I fixed the time problem.

The documentation of the CPAN library used sucks so it is difficult to know what that library actually does to the time and I personally do not understand why the time gets converted. It is not supposed to convert anything anywhere.

Please never follow up on an already closed report and leaving it closed. It is pure luck that I see it before it goes below the last 20 topics changed in Tasks web.

Always reopen - or better and more correctly - make a new report. I have reopened and assigned to myself.

-- KennethLavrsen - 09 Jun 2009

I found that the ACTIONSEARCH times were still being entered in localtime. Changed to GMT. Fixed unit tests.

Kenneth, when you get a chance, could you review and close this if it's all OK? Ta.

-- CrawfordCurrie - 05 Nov 2009

Noted. Will do very soon. Thanks for maintaining this fantastic plugin.

-- KennethLavrsen - 06 Nov 2009

Still a problem here on FW 1.07 (and 1.08) ActionTrackerPlugin 5434 (2009-11-05) I just created an item for 11-02-2013 and on save it reverted to 08-02-2013. 3 days! I'm in Pacific Standard Zone FWIW.

-- CraigBowers - 01 Dec 2009

I had a problem with FW 1.08 ActionTrackerPlugin(2009-11-05) In general I feel its wrong to assume GMT. We configure the wiki to use "servertime". Setting GMT => 0 fixed my problem.

Also currently relative dates in ACTIONSEARCH% do not work. We use due=">= last week" which no longer works. I traced it to Action.pm where pdopts are now being passed into the date matcher and they didn't used to be. I temporary fixed our instance by setting NO_RELATIVE => 0.

-- JacobChamplin - 04 Jan 2010

When you say "wrong to assume GMT" the point of the change I did was to avoid any conversion. Ie. when people enter a date this date is saved unmodified.

But it seems this only works if also server is GMT - otherwise there is still a conversion somewhere. There should be no conversion happening between data saved in the topics and the user inputs. There is no need for it. It is different with the internal time used by Foswiki vs what is displayed to the user.

Good input. I can see I need to setup some virtual machine with Linux and go through 4 scenarios.

• Foswiki uses servertime AND East of Greenwish server location
• Foswiki uses servertime AND West of Greenwish server location
• Foswiki uses GMT AND East of Greenwish server location
• Foswiki uses GMT AND West of Greenwish server location

We may need to adjust the code according to these facts to make it work.

-- KennethLavrsen - 05 Jan 2010

So, is this a bug in the core or the plugin or what? Is this item progressing where it is? As it is, the plugin is unusable. Not complain, but rather just trying to see what to track. I don't know protocol, but I made this Urgent; reset it if that is the wrong thing to do.

-- BigBaaadBob - 15 Mar 2010

I just installed ActionTrackerPlugin today, and I'm also seeing this issue. I'm in GMT+8 timezone. Whenever I edit an action, the due date changes to 2 days earlier than it was before. Weird!

-- LeilaPearson - 19 Aug 2010

I tried the fix above - removing GMT => 1 from the parsedate options - and it seems to work for me. I'm wondering why the fix isn't already in the plugin I downloaded today though? At least it makes it work for people who are editing actions in the same timezone as the server...

-- LeilaPearson - 19 Aug 2010

No it does not work for people east of GMT

We need a solution that works whereever you are

-- KennethLavrsen - 19 Aug 2010

Hmm... Given that the problem seems to center around Time::ParseDate and the documentation for that is so bad and the behavior so weird, I wonder if we should think about trying something like Date::Manip (http://search.cpan.org/~sbeck/Date-Manip-6.11/) instead. It looks very capable and the documentation is much better.

-- LeilaPearson - 20 Aug 2010

I tried the fix above - removing GMT => 1 from the parsedate options - and it does not work for me. My locale is GMT but we're as we're on summer time (BST) I'm an hour ahead. Without the this change dates were moving by two days, with this change the date is moving by one day.

Here is an action about to be added to the list:

This is what it looks like after (I've copied the "old" dates" in to the Description column for easier comparison.

I'm using the "action" option in the CommentPlugin.

I agree with previous comments about this being a option for collaboration. PLEASE PLEASE can this be rectified ASAP? I won't be rolling this out until this works.

-- BobCorless - 27 Aug 2010

Oops, I changed the wrong file. Changing action.pm as described above does appear to work for me. PC is GMT+1 and Server is EST.

-- BobCorless - 27 Aug 2010

Any action on this? My users have pretty much given up on it...

-- AaronFuleki - 28 Oct 2010

Aaron - at the moment I am busy with some more urgent plugins that do not work at all.

Aaron if you read the bug report carefully, then there is info how to alter the code if your server runs at a timezone west of GMT. For people east of GMT the code works.

We need to change the code so it works both places.

But until then Aaron just remove the GMT => 1 as described above and it will work for you. It does not matter what timezone your users are in. It is only the timezone of the server that matters.

-- KennethLavrsen - 28 Oct 2010

I took a stab at this today.

Further analysis showed that the fix I did last year was correct. But not complete.

My intension was to tell Time::ParseDate to not do any conversion relative to the server time. And that worked.

Unfortunately I had not noticed that we also have a conversion that is done in the Foswiki parseTime function if given 'servertime'.

Then we get the conversion another place. No matter what any conversion fails. We must save the exact date the user enters in the form. We must display the date that is saved. We must display this date when we open to edit. We must never convert anything.

I have fixed this and I have tested the following combinations

• Time Zone CET, 'servertime'
• Time Zone CET, 'gmtime'
• Time Zone EST, 'servertime'
• Time Zone EST, 'gmtime'

For EST I also tested the server running local time instead of GMT.

The tests I did was to edit actions, create actions, and perform action search where I used due="> DD MMM YYYY" checking that the searches worked.

So I feel confident that it works now.

But I would love to get feedback from those that upgrade the plugin. Both if it works and if there are still problems.

-- KennethLavrsen - 03 Nov 2010

Commenting is disabled while not logged in