Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Bug #913 (reopened)

Opened 11 years ago

Last modified 6 years ago

Sprint start-date can get moved to next day

Reported by: mhaecker Owned by:
Milestone: n.a. Sprint: n.a.
Impact: Medium Complexity: n.a.
Total Remaining Time: n.a.

Description (last modified by mhaecker)

I could reproduce this with starting a sprint on the 19.10.2009.

  • If I enter this value in the sprint admin panel it always gets shifted to the next day (20th)
  • If I add any hours to that value in the admin panel it always gets shifted to the 20th with hours set to midnight
  • If I set the 18th at midnight it still gets shifted to the 20th, at 11 o'clock it only gets shifted to the 19th
    • When this is edited via the roadmap page the timezone of me or the server is taken into account, i.e. 19.10.2009 00:00:00 to 19.10.2009 01:59:00 is shifted to the next day (but with hours left untouched, so they still read 01:59:00.

For these Tests I was on UTC+2 (client and server)

Change History (12)

comment:1 Changed 11 years ago by mhaecker

  • Description modified (diff)

comment:2 Changed 10 years ago by agilouser

Is this depending on the sprints_can_start_or_end_on_weekends setting?

comment:3 Changed 10 years ago by mhaecker

Setting this setting might mitigate the issue, but I would recommend to use the workaround described here.

comment:4 Changed 10 years ago by fschwarz

  • Impact set to Minimal

comment:5 Changed 9 years ago by agilouser

We can reproduce this issue in the following environment:

Operating System: FreeBSD 7.2-RELEASE

Python Environment:

py26-Genshi-0.5.1_3 < needs updating (port has 0.6) py26-MySQLdb-1.2.3 = up-to-date with port py26-flup-1.0.2 = up-to-date with port py26-pytz-2010o = up-to-date with port py26-simplejson-2.1.3 = up-to-date with port py26-subversion-1.6.15 = up-to-date with port python26-2.6.6 = up-to-date with port

Trac Environment:

trac-0.11.7 < needs updating (port has 0.12.2) trac-accountmanager-,1 > succeeds port (port has,1)

Agilo: 0.9.3 (source) installed as a local TRAC_ENV/plugin egg

Location: Sydney, Australia (CURRENTLY GMT+11 in daylight savings, normally GMT+10)

Additional Information:

We attempted to isolate the issue by trying various combinations of the following:

pytz installed and not installed trac: default_timezone set to NULL, +10, +11, Sydney/Australia trac User preferences set to UTC, GMT, +10, +11, Sydney/Australia (after installing pytz)

The calculations that determine whether the input date/time is a weekend or not are using UTC times, not localtimes.

As an example, in our current timezone (GMT+11):


Start_Time: Monday 07/03/2011 09:00:00 is 06/03/2011 22:00:00 in UTC which is a Sunday ,which changes it to the 08/03/2011 09:00:00

But if Start_Time is 07/03/2011 11:00:00 , then the shift doesnt occur because the time in UTC is 07/03/2011 00:00:00

Setting "sprints_can_start_or_end_on_weekends = true" avoids PART of the problem because it does not call shift_to_next_working day for the start date. When using DURATION it is still a problem as the end_date is still calculated in UTC incorrectly.

The problem manifests with ANY timezone whos offset is greater than the number of hours after midnight they want the sprint to start (See


comment:6 Changed 9 years ago by agilouser

  • Impact changed from Minimal to Medium
  • Version changed from 0.8.0 to

Updating version and impact (this was a "huge" POLA violation for us)

comment:7 Changed 9 years ago by mhaecker

Indeed, that is an issue. Maybe in that situation disabling sprints_can_start_or_end_on_weekends is a better workaround than moving start and end dates of sprints a few hours around.

comment:8 Changed 9 years ago by agilouser

That's the workaround we're using at the moment but this really should be fixed in the core.

I also notice #657 - which looks like it touched lots of areas in the codebase. Perhaps this is a regression/symptom of those changes, or the impact on calculations in local time was not considered when refactoring.

This intuitively doesn't feel like it will involve a lot of work, but instead primarily centred around identifying if any external functions rely on the is_weekend function doing the convert_to_utc calls for them.

I'd like to see this in the next Agilo release

comment:9 Changed 9 years ago by mhaecker

I would too, and I will raise this with our product owner to influence his decision. On the bug: we have found that timezone issues tend to be tricky to deal with in the past, so lets see how much work this turns out to be.

comment:10 Changed 9 years ago by stefano

  • Resolution set to fixed
  • Status changed from new to closed

Closed by r3242, timezones are now considered in weekend shifting.

comment:11 Changed 9 years ago by stefano

  • Resolution fixed deleted
  • Status changed from closed to reopened

The fix for this bug has been reverted. We are tracking this internally as #63

comment:12 Changed 6 years ago by stefano

I was able to reproduce this on version 0.9.13

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.15 © 2008-2016 Agilo Software all rights reserved (this page was served in: 0.130883 sec.)