Am 11.09.2009 08:12, schrieb Chris Manning:
As shown here http://img29.imageshack.us/img29/9389/burndown.png. I can only assume they are to do with timezone issues (I tried having a look at the code but rapidly got lost in all the conversions to and from utc). I am in New Zealand, and have the timezone on the server and within trac set to Pacific/Auckland.
New Zealand is UTC+12 currently? Pacific/Auckland is UTC+13 currently?
There are several things about the attached burndown that don't make sense to me. 1) Whilst the weekends are shaded in the correct places, the capacity and ideal burndown lines seem to be offset by a day (I assume the flat part should be over the weekend).
I guess so :-)
2) The actual burndown does not seem correct to me. Since starting this sprint I have completed two tasks. The first was at 6:45pm on the 10, and reduced the remaining time by 12h. The second was at 3:45pm on the 11th and reduced the remaining time by 6h. The way I understand that it should work is that the dot at the beginning of the 11th should be at 54h (instead of the 66 it is at) as the work had been done by then, and that the dot part way through the 11th should be at 48h (instead of the 54 it is at), as the work has been done between the start of the day and now.
This sounds correct but I suspect that this is the same problem as with the weekends.
> this incorrect behaviour likely down to a setup issue on my end, or a bug in the system?Are my assumptions correct in the way this should work, and if so is
I guess you're triggering an edge case. Conversions with UTC+13 are a bit tricky as it's easy to get the mathematics wrong there...
Is there any chance that we get a copy of your environment? fs
smime.p7s
Description: S/MIME Cryptographic Signature
