[Patch] Milestones with no due date are shown one day late

[Ryan J Ollos]

With this patch, things looks correct:

0.11/tracjsgantt/tracjsgantt.py

@@ -773 +777 @@
                 # Milestones are always shown
                 milestoneTicket['level'] = 0
                 
-                # If there's no due date, default to today at close of business
-                ts = row[1] or \
-                    (datetime.now(utc) + 
-                     timedelta(hours=options['hoursPerDay']))
+                # If there's no due date, default to today
+                ts = row[1] or datetime.now(utc)
                 milestoneTicket[self.fields['finish']] = \
                     format_date(ts, self.dbDateFormat)

[Chris Nelson]

I see this a little off, too. But I'm not convinced the patch is the right fix. Logically, the patch does the right thing: it sets the time/date for the due date to the end of the day. Of course, I'm a little unclear what "now" is. Isn't it clock time?

[Chris Nelson]

(In [10865]) Make default due date handling consistent. Refs #9443.

There were two methods of setting a default due date. For milestones we used datetime.now(utc) but for tickets we used datetime.today(). The two methods required different formatting when converting to string. This makes the two uses consistent.

[Chris Nelson]

(In [10866]) Tweak milestone placement in day mode. Refs #9443.

With this change, the milestone shows up on the border between days in FF 7.0.1 on Ubuntu at default magnification. Zooming in with Ctrl-+, shifts the milestone's diamond to the right. The shift seems to be worse as you go further to the right on the chart.

I believe this is an improvement but I need to figure out why the shift happens.

[Ryan J Ollos]

Replying to ChrisNelson:

I see this a little off, too. But I'm not convinced the patch is the right fix. Logically, the patch does the right thing: it sets the time/date for the due date to the end of the day. Of course, I'm a little unclear what "now" is. Isn't it clock time?

You are right. I realize now that my patch was not correct since we want the due date to be the end of the day, not now with microsecond resolution.

The problem with the change in [10865] is that the user's timezone preference will not be taken into account since it doesn't use Trac's datefmt class. We didn't have proper behavior to begin with (I've been meaning to open a ticket for this and provide a patch), but we were moving in the right direction by using format_date in [10407]. This is a significant issue if your server is in a different timezone than you are in, as is the case for me.

I have some experience working with a similar patch for the Trac core, see ​[t 10022] and ​comment:22:ticket:6369. I'll have to sit down and work on a patch to be sure, but I believe the correct way to do things is to work with non-naive datetime objects as generated by datetime.now(utc), and use format_date and format_datetime to generate strings for printing.

>>> print datetime.now(utc)
2011-11-02 16:10:54.056176+00:00

>>> print datetime.now(utc).replace(hour=0,minute=0,second=0,microsecond=0)
2011-11-02 00:00:00+00:00

>>> print format_datetime(datetime.now(utc))
11/02/11 09:11:58

[falkb]

[10866] results to the following callstack here (as wronly reported in ticket/8998):

...
  File "build\bdist.win32\egg\tracjsgantt\tracjsgantt.py", line 1060, in _add_tasks
    self._add_milestones(options)
  File "build\bdist.win32\egg\tracjsgantt\tracjsgantt.py", line 785, in _add_milestones
    ts.strftime(self.dbDateFormat)
AttributeError: 'long' object has no attribute 'strftime'

[Chris Nelson]

Need to convert the "long" milestone due date to a datetime. Working on it...

[Chris Nelson]

(In [10875]) Revert "Make default due date handling consistent. Refs #9443."

This reverts commit a16d6abc70b1ab724f5a0236625440ce00a4602d.

This introduces a bug. To say nothing of the fact that it doesn't seem to address the problem. While the placement of the milestone diamond is wrong, when I view page source the time of the milestone start and finish is the end of the day so the problem is in the drawing.