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

With this patch, things looks correct:

• 0.11/tracjsgantt/tracjsgantt.py

  old	new
  773	777	# Milestones are always shown
  774	778	milestoneTicket['level'] = 0
  775	779
  776		# If there's no due date, default to today at close of business
  777		ts = row[1] or \
  778		(datetime.now(utc) +
  779		timedelta(hours=options['hoursPerDay']))
  	780	# If there's no due date, default to today
  	781	ts = row[1] or datetime.now(utc)
  780	782	milestoneTicket[self.fields['finish']] = \
  781	783	format_date(ts, self.dbDateFormat)

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?

(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.

(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.

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

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

...
  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'

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

(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.