Changes between Version 17 and Version 18 of TracTicketsCustomTimeFields
- Timestamp:
- Apr 17, 2010, 3:50:13 AM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracTicketsCustomTimeFields
v17 v18 53 53 Problems on ticket change/preview 54 54 * fixed: move to microsecond timestamp caused a mess with calculations (added '* 10E07' instead of '* 10E06' and the like) 55 * current date is injected whenever time field is left/made empty 56 * notification unpatched, throwing an error note related to unexpected datetime.datetime input to [TracNotification Trac Notification] system 55 57 56 58 ==== Making ''mxDateTime.Parser'' an option ==== 57 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.59 While there was working code for parser functions before and I was especially satisfied with the performance of the needed date/time parser I've re-arranged the implementation. Now ''mxDateTime.Parser'' is not a dependency but an option. This was suggested by cboos and others for the sake of maintaining Trac code highly self-sufficient, and I understood this a feature on its own. Still ''mxDateTime.Parser'' has superior performance, if it comes to more unusual date/time user input, so it is still a recommended for maximum user satisfaction. 58 60 59 61 ==== Time stamp format ==== … … 64 66 65 67 === Discussion === 66 ==== Additional code dependencies====68 ==== ''No'' additional code dependency, but an option ==== 67 69 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. 68 70 (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. 69 71 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. 72 See above about improved implementation, so this should be no problem anymore. 70 73 71 74 ==== Considering demand for custom time field defaults ==== … … 120 123 [http://docs.python.org/tutorial/index.html The Python Tutorial] - the 'official' one[[BR]] 121 124 [http://www.tutorialspoint.com/python/index.htm Python Tutorial] - and another[[BR]] 125 [http://openbookproject.net/thinkcs/python/english2e/index.html Learning with Python 2nd Edition] at openbookproject.net[[BR]] 126 [http://www.sqlite.org/docs.html SQLite Documentation][[BR]] 122 127 [http://hgbook.red-bean.com/ Mercurial: The Definitive Guide] by Bryan O'Sullivan[[BR]] 123 [http://mercurial.selenic.com/wiki/FAQ Mercurial Frequently Asked Questions] 128 [http://mercurial.selenic.com/wiki/FAQ Mercurial Frequently Asked Questions][[BR]] 129 [http://ches.nausicaamedia.com/articles/technogeekery/using-mercurial-queues-and-bitbucket-org Using Mercurial Queues and bitbucket.org] - a semi-official guide
