Documentation for formatting dates going in imported data?

Mac & Windows (Desktop)
#1

[Using v3.4.18 on macOS 15.3]

Is there any documentation on the format used in a text file for date-type field data to import into Aeon Timeline? I can’t find the app’s manual, other than the online KB which doesn’t cover much. Does the import have any understanding of partial dates? If the date I have is 1861, can I import it as 1861' or 1861//`, etc., or must I use a full y m & d and then remove the latter?

The import dialog† offers dd/mm/yyy, mm/dd/yyyyoryyyymmdd`. That would suggests I have to supply fake month and day info to get import to work.

Does Aeon Timeline have any notion of partial dates of convention for such , e.g. using 1 for missing day and/or month?

†. Annoyingly, you only get to see this having selected a valid import file … which you don’t yet know how to make!

#2

Hey, Mark. Aeon isn’t really so bad. Here’s the format of the file.

It’s either a tab separated or a comma separated file, your choice. It should have a header row, but it doesn’t matter what the headers are as long as you can recognize which column is which.

You need to have a column for labels, which can be titled anything you want.

When you choose File->Import, Aeon will present a dialog for you to choose how to map columns in your input file to values in Aeon. Dates are interpreted pretty well.

I exported the Wuthering Heights demo timeline and used Easy Data Transform to convert dates in the form YYYY-MM-DD to MM/DD, and dates in the form of YYYY-MM (without a day) to MM/01.

Anything without a day will appear with a precision of one month. Anything without a month will have a precision of one year.

Aeon imported my butchered CSV file without issue.

I’ve used Aeon as much for correspondence tracking as creative writing, and one thing I get a kick out of is directly exporting from Devonthink into Aeon.

I have custom metadata fields in Devonthink for start, end, duration, participant, location, arc, and a couple of other things of interest.

Devonthink will create a metadata summary that’s a tab separated file of all the metadata for selected records. That file feeds directly into Aeon without modification.

I also wrote a simple script to translate an export from Curio. The script writes a CSV file that Aeon is happy with, picking metadata out of note attachments (everything in Curio has a note) in the form @@start, @@participant, etc.

Hope that helps.

#3

Thanks. BTW: I’ve no downer on Aeon Timeline and actually have significant past experience of beta testing data import/export to it. I also regularly recommend it to folk. But, the documentation is a bit sparse.

This is the key fact I needed and thanks for the clarification. It’s sufficiently important, given dates are key to the apps purpose, that I assume it would be in the documentation ( a KB’s fine if it actually has the needed info). Otherwise black-box testing still only gives the appearance of success. Knowing the appp’s design intent is the work of seconds to document but gives much need clarity.

As you note timeline work lives in an ecosystem of PKM tools , I too use DEVONthink and Easy Data Transform. In this case the data is c.600 events scraped from a badly formatted PDF → Tinderbox for review proofing & TSV file formatting → Aeon Timeline (BBEdit in the wings for snagging the import file.)

Anyway, very happy that partial dates are supported/understood as that’s an uncommon affordance. The earliest/latest support is good too, though I don’t need it here I used a lot in the past working with Simile Timeline.

I should now be able to fettle the Timeline in ATv3 then export and re-import to ATv2 for the final step of web export. The lack of that is why I’ve used AT less of late—I generally need the timeline in a web-presentable form. In this case is is some experimental timeline use in an XR environment.

Thanks again and glad to be re-connecting with AT. :slight_smile:

#4

I hope I can help. I like AT but also see where it could be much stronger. For instance, if the summary were something that could be opened in a separate edit window. Imagine if AT had Scrivener-like editing capabilities.

Regarding documentation, you’re right. It has improved a lot but it’s still easy to get confused in the edges of the software, like data type relationships.

I guess what’s needed is some kind of living document, a universal Aeon Timeline reference.

It would have to have a catchy name, though. I dunno, maybe something like anAtRef? Maybe that naming style has been taken, seems like I’ve seen something similar somewhere. :wink:

By the way, Tinderbox is really cool. The community support is outstanding, and the meetup calls are superlative.

#5

:slight_smile: FWIW, I am the author of aTbRef! (I’ve a hunch you guessed that :slight_smile: ). But, aTbRef is 24+ years of iterative work by a user and my comments weren’t an oblique nod to that. I did it to learn the app and stayed to record lessons from lots of edge cases and things unguessable. Still, it’s taught me that vendor documentation is not easy, not least as it is hard to remember what isn’t ‘intuitive’ once we know. I’m not here to throw stones.

Still, case in point ‘hiding’ important proceedural info in dialogs that can only be opened using a file whose format one’s still trying to understand is an unintentional shot in the foot. No blame, just an unforced error and (hopefully) easily resolved.

1 Like
#6

You are to be congratulated - aTbRef is part of Tinderbox’s foundation, and I agree that documentation is key to usability.

That’s something that gave me a dislike for Agile. One of the four cornerstones of Agile is working software is more valued than comprehensive documentation.

My most complex project to date grew to about 200 pages of assembly language over a span of about 15 years. I was the sole developer. The product was very successful and I’m proud that after the first few months of production we didn’t have any software related crashes. We kept that record through 15 years of evolution and feature upgrades.

Nothing in that project, nor in any major effort I’ve been in control of since, has begun with code or an IDE. Every complex project, if it’s going to be successful, starts with a word processor and organized notes.

Anyway, it’s a pleasure to meet you, Mark. If my meager grasp of Aeon can be of any help, I always like to investigate use cases.

2 Likes