Changes between Version 12 and Version 13 of TracTicketsCustomTimeFields
- Timestamp:
- Apr 6, 2010, 11:36:25 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracTicketsCustomTimeFields
v12 v13 1 1 = Custom Ticket Time Fields = 2 3 2 This page presents information on adding a new type 'time' to the list of all currently available [wiki:TracTicketsCustomFields custom ticket fields]. 4 3 … … 23 22 * [th:wiki:AnnouncerPlugin AnnouncerPlugin], modified version produces reports with pretty date/time strings, private patch done 24 23 24 === Status of Development === 25 Code was published in a Mercurial repository (see ''custom-time'' branch) at 26 http://traccustom-time.hg.sourceforge.net:8000/hgroot/traccustom-time/traccustom-time 27 currently with SVN changes up to trac SVN changeset r9442. 28 29 Feedback could happen through 30 * comments to #1942, 31 * edits to (the discussion section of) this wiki page, 32 * private e-mail, or 33 * commits to VCS after initial per-developer arrangement inside the Sourceforge project. 34 * chat while I'm arround in IRC channel #trac at freenode.net 35 36 ==== Known Bugs ==== 37 I recognized at least a glitch on creation of new tickets that needs to be fixed ASAP. 38 39 ==== Making ''mxDateTime.Parser'' an option ==== 40 While there is working code for all intended functions and I'm especially satisfied with the performance of the needed date/time parser I'll try to change it's implementation. Making ''mxDateTime.Parser'' just an (still recommended) option but not a dependency, like cboos suggests, clearly justifies some effort for the sake of maintaining Trac code highly self-sufficient. 41 42 ==== Time stamp format ==== 43 There was no argument against storing time stamps as string to arrange with current type definition "string" for values in ticket_custom db table. But switching to microseconds time stamp format recently adopted for Trac internal time fields ''time'' and ''changetime'' seems to be better than sticking with the former Unix time stamp, even if I prepared support for fractions of seconds by converting custom timestamps to float before. 44 45 ==== Unit tests ==== 46 I got [ticket:1942#comment:23 advice], that presence of this would be a pre-requisite for inclusion into Trac. 47 25 48 === Discussion === 26 49 ==== Additional code dependencies ==== 27 50 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. 28 51 (cboos): adding a new external dependency is a strong handicap for being considered for inclusion in Trac core. Have you really weighted the benefits of using mxDateTime? Maybe that helps to kick start the development, but you should really consider building your own utility functions, if you need functionality besides the one provided by the `datetime` classes. See for example how we integrate `pytz`: if present, we take benefit from it, if not, we provide our own replacement with reduced functionality. 52 Actually I put it in here, just because I expected opposition against this dependency. I understand your point and made this an own topic under the [#StatusofDevelopment development section] above. 29 53 30 54 ==== Handling ticket changed notification ==== 31 55 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. 56 As adoption of code from [th:wiki:AnnouncerPlugin AnnouncerPlugin] is far from ready to replace current Ticket Notification, I feel the need to patch it as well. Right? 32 57 33 === Status of Development === 34 There is working code for all intended functions. I recognized a glitch on creation of new tickets that needs to be fixed. 58 ==== Development trace ==== 59 Happened to have access to !SourceForge, so I choose to go and push code into a Mercurial repository there to enable collaboration based on a distributed VCS as per suggestion from IRC channel #trac at freenode.net. 60 rblank offered to rebase my code on top of code from his own repository, so a least he would be able to rewiev more easily. I'll try it and combine this move with a trial on Mercurial patch queue. 35 61 36 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: 37 http://traccustom-time.hg.sourceforge.net:8000/hgroot/traccustom-time/traccustom-time 38 39 Feedback could happen now through 40 * comments to #1942, 41 * edits to the discussion section of this wiki page, 42 * private e-mail, or 43 * commits to VCS after initial per-developer arrangement inside the Sourceforge project. 44 45 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?). 62 Current development is based on Trac-0.12dev_~~r9115~~r9442 (see current state), testet with Python2.5 on ''Debian GNU/Linux'' stable. However it would be great to have it in trunk soon (trac-0.12.x?). 46 63 (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). 47 64 Ah, well, thanks for the hint. We're at r9420 right now, any recommendation where to start from other than HEAD? 48 65 (cboos): why not HEAD? Latest trunk should be fine. We're about to release a rc1 or a beta soon, so that might provide a stable basis. 66 The question was obsoleted by current development. And I'll continue to work hard to keep pace and match all reasonable demands ASAP. 49 67 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. 50 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. 51 Halfway done, 11 merges are in the repository now, most importantly merged with the microseconds time stamp changeset r9210. In fact especially that changeset was not at all related to my modifications. I didn't touch my old function, that still uses ''to_datetime(ts)'' instead of the new ''from_utimestamp(ts)''. I don't use ''to_timestamp(dt)'', but the conversion from within class ''mxDateTime.!DateTime.ticks()''. However for the sake of clarity I think it will be good to shift to microseconds timestamps for custom timefields too. So this is on my !ToDo after finishing the whole merge marathon. 68 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. 69 Halfway done, 11 merges are in the repository now, most importantly merged with the microseconds time stamp changeset r9210. In fact especially that changeset was not at all related to my modifications. I didn't touch my old function, that still uses ''to_datetime(ts)'' instead of the new ''from_utimestamp(ts)''. I don't use ''to_timestamp(dt)'', but the conversion from within class ''mxDateTime.!DateTime.ticks()''. However for the sake of clarity I think it will be good to shift to microseconds timestamps for custom timefields too. So this is on my !ToDo after finishing the whole merge marathon. 70 '''Done''', merged changes for custom time field support with SVN changes up to trac SVN changeset r9442. 52 71 53 72 == Related tickets == … … 69 88 [http://docs.python.org/tutorial/index.html The Python Tutorial] - the 'official' one[[BR]] 70 89 [http://www.tutorialspoint.com/python/index.htm Python Tutorial] - and another[[BR]] 71 [http://hgbook.red-bean.com/ Mercurial: The Definitive Guide] by Bryan O'Sullivan 90 [http://hgbook.red-bean.com/ Mercurial: The Definitive Guide] by Bryan O'Sullivan[[BR]] 91 [http://mercurial.selenic.com/wiki/FAQ Mercurial Frequently Asked Questions]
