Changes between Version 6 and Version 7 of TracTicketsCustomTimeFields

Timestamp:

Apr 3, 2010, 1:18:12 AM (14 years ago)

Author:

hoff.st@…

Comment:

updated comment on repository, reply to hint on new microseconds unix time

TracTicketsCustomTimeFields

@@ -29 +29 @@
 There is working code for all but the notification stuff (only plain unix time stamp values in change notes). Sure, this will be fixed soon too.
 
-I choose Mercurial to enable further collaboration based on a distributed VCS as per suggestion from IRC channel #trac at freenode.net: 
+Happen to have access to !SourceForge, so I choose to go there and push code into a Mercurial repository there to enable further collaboration based on a distributed VCS as per suggestion from IRC channel #trac at freenode.net: 
  http://traccustom-time.hg.sourceforge.net:8000/hgroot/traccustom-time/traccustom-time
 
@@ -40 +40 @@
 Current development is based on Trac-0.12dev_r9115, testet with Python2.5 on ''Debian GNU/Linux'' stable. However it would be great to have it in trunk soon (trac-0.12.x?).
   (cboos): that's way too old to base new development upon, especially for timestamp related development, as r9210 introduced a big change here (time are now stored as microseconds elapsed since epoch, as bigints).
-
+    Ah, well, thanks for the hint. We're at r9420 right now, any recommendation where to start from other than HEAD? I'll have to reinstall my test platform here and re-base changes then. However starting with standard unix time seconds was easier to debug for me (i.e. comparing to date +%s). And to_timestamp() messed up the date values converted from mxDatetime for some reason. I went for the included mxDatetime.Datetime.ticks() function to get good unix time seconds. So I may still need an own function to calculate unix time microseconds from unix time seconds.
 == Related tickets ==
  #710 asking for basic time tracking in Trac, especially missing native ''due_date'' and custom field type 'numeric'[[BR]]