Changes between Version 10 and Version 11 of TracTicketsCustomTimeFields

Timestamp:

Apr 5, 2010, 10:43:54 PM (14 years ago)

Author:

hoff.st@…

Comment:

added comment on current development, especially the important merge of trac changeset r9210

TracTicketsCustomTimeFields

@@ -46 +46 @@
     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 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.
+        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.
 
 == Related tickets ==