Changes between Version 9 and Version 10 of TracTicketsCustomTimeFields

Timestamp:

Apr 5, 2010, 2:00:45 AM (14 years ago)

Author:

hoff.st@…

Comment:

updated development comment

TracTicketsCustomTimeFields

@@ -45 +45 @@
   (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.
-      Checked changes between r9115 and r9420, preparing a merge this weekend.
+      Checked changes between r9115 and r9435, prepare for updates this weekend. Found 23 changesets that did modify files I touched by now. Sounds quite big. Try to figure out a way to do it save for now, postpone to do it clever with least effort later. Might want to use Mercurial Queues or the like, but I fell I don't understand all the consequences.
+
 == Related tickets ==
  #710 asking for basic time tracking in Trac, especially missing native ''due_date'' and custom field type 'numeric'[[BR]]
- #1942 the main resource on requests and considerations related to the topic[[BR]]
+ '''#1942 the main resource''' on requests and considerations '''related to the topic'''[[BR]]
  #1943 asking for time based calculations in queries, essentially based on #1943[[BR]]
  #1962 asking for due dates on tickets & email notification on overdue dates, several tricks and workarounds needed for using date strings the way you'd expect true time values to match, sort, etc.[[BR]]
@@ -55 +56 @@
  #6466 asked for higher time stamp precision introduced with microseconds for ''time'' and ''changetime'' in r9210
 
-FIXME: already seen much more related, put it in here
-
 == External related resources ==
 Ideas and Open Source code was shamelessly taken from the following places:
@@ -62 +61 @@
  ![2] [http://www.egenix.com eGenix.com], especially see ''mxDateTime'' [http://www.egenix.com/products/python/mxBase/mxDateTime/doc/#DateTime related documentation][[BR]]
  ![3] [http://docs.python.org/library/datetime.html#module-datetime Basic date and time types] from module ''datetime'' in Python>=2.3
+
+Needed help about Python and development tools and found it i.e. at:
+ [http://docs.python.org/tutorial/index.html The Python Tutorial] - the 'official' one[[BR]]
+ [http://www.tutorialspoint.com/python/index.htm Python Tutorial] - and another[[BR]]
+ [http://hgbook.red-bean.com/ Mercurial: The Definitive Guide] by Bryan O'Sullivan