Hi, Thanks for reporting this, it looks like a problem in the program, which we will look into and provide a fix for in a future update. Jess
Hi, I have looked into this one more closely. Firstly, there is a bug that I have fixed: the intention when exporting to CSV is to always include a time component in the dates, but this was incorrectly omitted for the first date format (it only included a time when it needed to). So I have corrected that so that time is always included in the export for the next release. Then it gets a little trickier: For background on how we choose to display end dates, read the section called "Representing end dates and midnight" on this page: https://www.aeontimeline.com/support/representing-dates-and-durations/ In short, we choose to treat end dates as "inclusive", so something going from 7-9 November 2016 means from the start of Nov 7 to the end of Nov 9, which we choose to represent as 9 Nov 2016 24:00:00 if required to provide a time. Note that "9 Nov 2016 24:00:00" is the exact same time (mathematically) as "10 Nov 2016 00:00:00", we just feel the former representation feels more natural as it allows us to be consistent with the "inclusive" end dates approach. When export ing to CSV, we are left with a dilemma. Do we use this same format, and potentially confuse other applications that aren't expecting the legal but less common 24:00:00 representation, or should we switch to the more conventional latter option. At present, we have opted for the conventional representation, which would use "10 Nov 2016 00:00:00" to represent the end of the previous day. Given that CSV export is primarily for importing into other applications that might try to interpret the date and time programatically, I still feel this is the correct choice... even though it means the dates are off-by-one compared with what we show. Hopefully, this ambiguity is less concerning with the full time component included. Matt
Thanks for the very prompt and constructive response.