| | 1 | = Custom Ticket Time Fields = |
| | 2 | |
| | 3 | This page presents information on adding a new type 'time' the list of all currently available [wiki:TracTicketsCustomFields custom ticket fields]. |
| | 4 | |
| | 5 | == Proposed Implementation == |
| | 6 | === Trac core === |
| | 7 | * add 'time' to available types, inheriting most of the definition from 'text', a simple (one line) text field[[BR]] |
| | 8 | |
| | 9 | At that point TracQuery already works as intended by providing from..to |
| | 10 | input fields on selection of custom time fields for query. |
| | 11 | Praise to the flexible, modularized software design of Trac developers! |
| | 12 | |
| | 13 | * extend ''ticket.model'', ''ticket.web_ui'', ''util.datefmt'' and ''ticket/templates/ticket.html'' to |
| | 14 | * allow for reading unix time stamp values from db table ''ticket_custom'' |
| | 15 | * convert unix time stamp values to localized time string |
| | 16 | * parse user input and consolidate different flavors of time stamps |
| | 17 | * write back unix time stamp to db |
| | 18 | * send out properly formatted notification |
| | 19 | |
| | 20 | === Related Trac Plugins === |
| | 21 | * provide a patch for [th:wiki:CustomFieldAdminPlugin CustomFieldAdminPlugin] to ease the setup for new field type |
| | 22 | |
| | 23 | === Discussion === |
| | 24 | ==== Additional code dependecies ==== |
| | 25 | 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. |
| | 26 | |
| | 27 | === Status of Development === |
| | 28 | 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. |
| | 29 | |
| | 30 | So I'm looking forward on getting feedback about the way to contribute it to trac development. Current development is based on Trac-0.12dev_r9115 working with Python2.5 on ''Debian GNU/Linux'' stable. It would be great to have it in trunk soon (trac-0.12dev?). |
| | 31 | |
| | 32 | == Related tickets == |
| | 33 | #1942 - the main resource on requests and considerations related to the topic |
| | 34 | FIXME: already seen much more related, put it in here |
| | 35 | |
| | 36 | == External related resources == |
| | 37 | Ideas and OS code was shamelessly taken from the following places: |
| | 38 | ![1] [http://seehuhn.de/pages/pdate Date and Time Representation in Python] by Jochen Voss[[BR]] |
| | 39 | ![2] [http://www.egenix.com eGenix.com], especially see ''mxDateTime'' [http://www.egenix.com/products/python/mxBase/mxDateTime/doc/#DateTime related documentation] |
