aeontimeline

Open full view…

Date error in CSV export

paulkelly
Sat, 08 Jul 2017 23:23:30 GMT

I have a file with about 70 events, each of duration between two and 30 days. All start and end dates are specified to the precision of a day, with no times shown. When I export the file as a CSV, all the end dates in the CSV file are one day later than the dates shown inside Aeon. Any ideas what I am doing wrong, or why the program is getting it wrong?

aeonjess
Sun, 09 Jul 2017 02:38:12 GMT

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

Matthew Tobin
Sun, 09 Jul 2017 04:25:15 GMT

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

paulkelly
Sun, 09 Jul 2017 10:44:08 GMT

Thanks for the very prompt and constructive response.