Opened 5 years ago

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

Reported by: Owned by: rjollos ChrisNelson normal TracJsGanttPlugin normal 0.11

### comment:1 Changed 5 years ago by rjollos

With this patch, things looks correct:

• ## 0.11/tracjsgantt/tracjsgantt.py

 # 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)

### comment:2 follow-up: ↓ 5 Changed 5 years ago by ChrisNelson

• Status changed from new to assigned

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?

### comment:3 Changed 5 years ago by ChrisNelson

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

### comment:4 Changed 5 years ago by ChrisNelson

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

### comment:5 in reply to: ↑ 2 Changed 5 years ago by rjollos

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


### comment:6 Changed 5 years ago by falkb

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

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


### comment:7 Changed 5 years ago by ChrisNelson

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

### comment:8 Changed 5 years ago by ChrisNelson

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