Changes between Version 8 and Version 9 of TracTicketsCustomTimeFields

Timestamp:

Apr 3, 2010, 10:15:13 PM (14 years ago)

Author:

hoff.st@…

Comment:

comment on current development, discuss notification stuff

TracTicketsCustomTimeFields

@@ -1 +1 @@
 = Custom Ticket Time Fields  =
 
-This page presents information on adding a new type 'time' the list of all currently available [wiki:TracTicketsCustomFields custom ticket fields].
+This page presents information on adding a new type 'time' to the list of all currently available [wiki:TracTicketsCustomFields custom ticket fields].
 
 == Proposed Implementation ==
@@ -19 +19 @@
 
 === Related Trac Plugins ===
- * provide a patch for [th:wiki:CustomFieldAdminPlugin CustomFieldAdminPlugin] to ease the setup for new field type
+ * [th:wiki:CustomFieldAdminPlugin CustomFieldAdminPlugin], modified version to ease the setup for new field type, private patch done
  * [th:wiki:DateFieldPlugin DateFieldPlugin] working like a charm with new time field, since it's still simple text input form field
+ * [th:wiki:AnnouncerPlugin AnnouncerPlugin], modified version produces reports with pretty date/time strings, private patch done
 
 === Discussion ===
@@ -26 +27 @@
 Amongst the few new dependencies use of ''eGenix.com'' time string parser ''mxDateTime.Parser'' for Python is the most notable one ![2]. We need to add such a powerful tool to provide a mature parser right from the start. If handled with care, similar but incompatible classes ''datetime.datetime'' and ''mxDateTime.!DateTime'' are not much of an issue. In fact it doesn't matter at all, as long as we stick to unix time stamp format for saving times in the db for other (good) reasons as well.
 
+==== Handling ticket changed notification ====
+I plan to let the notification system handle the conversion of unix time stamp values to date/time strings on it's own. I tested with a patched version of [th:wiki:AnnouncerPlugin AnnouncerPlugin] that worked. This is a good start for the [wiki:TracDev/Proposals/Announcer proposed replacement] of current Trac Notification System by Code from [th:wiki:AnnouncerPlugin AnnouncerPlugin]. This might even make per-user preference-based date/time formatting possible in the future.
+
 === Status of Development ===
-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.
+There is working code for all intended functions. I recognized a glitch on creation of new tickets that needs to be fixed.
 
 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: 
@@ -41 +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.
 == Related tickets ==
  #710 asking for basic time tracking in Trac, especially missing native ''due_date'' and custom field type 'numeric'[[BR]]