I’m working on some family history and many dates are approximate. I’d like to store these as date attributes to be able to use the timeline. What are some of the ways folks here have dealt with this?
Simplest solution for me has been to “round up” - so if for example I know the month but not the date, I use the first of the month. If the year but not the month, I use mid-year or July 1. For unspecific hour, 12:00 works.
Whichever I use, I always ensure it’s a valid date format. This keeps the integrity of the Attribute values uniform and eases searches.
I like the idea of “rounding to the middle” that you use for the year. I may adopt that. I’m not using times so I arbitrarily set that to 1:00. Another thought would be to assign a “rating” to the date. Something like 1 = poor, 5 = accurate. The problem with that is that I’d have to double up on all the different date attributes unless I encoded it into the time.
If you want to rate date (accuracy) and are not using times, you might consider using an odd time value to indicate the level of confidence in the date. I would use something like 1:10, 1:11, 1:12, 1:13, 1:14, 1:15. This way as your calculations get more precise you can edit the timestamp accordingly. It’s also possible to generate values for another (user) Attribute, say $DateConfidence (ToChange/Low/Medium/Good/Precise), from reading the minute value on your timestamp.
Exactly. I’m going with some version of that.
Another approach, for the situation where the rough but not exact date is knows in so you two pairs of dates, supplementing $StartDate & $EndDate (or equivalent pair of Date-type attributes) with two more $StartDateAfter and $EndDateBefore. this allows for a fuzzy’ period at start and end of a date or date rage.
As far as I know there is no generally standardised method for incomplete dates. String fields can be used to partial dates, e.g. as ‘Oct 1953’ or ‘Oct’ and ‘1923’. It all depends on what you want to do with the information. If you want to do date arithmetic, Date-type attributes support this better, though. as already discussed they have no notion of a partial date). Dates are simply a number of milliseconds before or after a specific reference date and have no built-in method to indicate the date is in some way ‘partial’.
When I was working in history I “rolled my own” – I had user attributes for $Year, $Month and $Day, plus a $DateModifier which could be “circa”, “before”, “after” or whatever I wanted. I found this a lot easier than working with the built-in date attributes. When working with biographical data I had $BirthYear, $BirthMonth, etc. It allows you to do a lot more with your data.
3 Likes
Thanks. I’m parsing dates from $Text so I can do something like this. I was trying to avoid lots of date-like user attributes, but this suggestion gets me closer to what I want to do.
Don’t worry unduly about getting it right in terms of attributes (type, name, default values, etc.) as Tinderbox is very forgiving of making changes if they become necessary. If unsure how, just ask if when the time codes. The main pint is it will not be a complete restart as it might be in some apps.
Also, even if your primary data capture is as String type date, the date(dateStr) and date(yearNum, monthNum, dayNum[, hourNum, minNum]) operators make it easy to make Date-type info should the need arise to do some date arithmetic.
Have you thought of using ISO 8601 (see eg How to be uncertain with dates) or the Library of Congress Extended Date Time Format (Extended Date Time Format (EDTF) Specification (Library of Congress))? The latter covers everything that I would have thought you might need — exact dates, uncertain dates, partially known dates, date ranges (fully bounded, starting, ending, uncertain).
I’d not recommend “rolling your own” when there’s a well thought through and documented standard with external libraries (eg Python) that support it.
We might want to re-check that—or have you just tested? I note this as I believe the ISO year-first yyyy-mm-dd layout may be accepted now, even if it wasn’t when probably first documented date-string detection/parsing by date().
I wonder how many historians are familiar with Python. I know it is named after a large snake, and that is the limit of my knowledge.
As to using ISO, one problem is that if you enter a date in ISO format into one of the built-in Date attributes in Tinderbox, it gets automatically converted into another format, with the time appended to it (whether you wanted that or not) – typically the time when you entered the date. And it seems that the modifiers mentioned in the article you linked get stripped out. Moreover, as the author of the article says:
Speaking as a member of the Data Workers Union (Boring Old Fart Division), I’d say the ISO 8601 date format extensions are impressive but unlikely to be widely adopted. You’d need a cheat sheet or a carefully written parser to translate them, as well a metadata explainer for your data compilations …
I still like the idea of a separate date-notes field to explain uncertainties …
Basically, I’d still roll my own. But thank you for linking the article. Still very useful to know about, though I wouldn’t use the method.
Fun factoid about the name, via the Python Institute:
Python was created by Guido van Rossum, and first released on February 20, 1991. While you may know the python as a large snake, the name of the Python programming language comes from an old BBC television comedy sketch series called Monty Python’s Flying Circus.
As to Tinderbox Dates and ISO 8601:
Two points here, format and time.
- The format you see after entering a date is as set in the Document Settings, Text tab’s Displayed Attributes date format control which allows any of 3 formats to be selected form a pop-up menu. This can be overridden with custom choice of date format string being set at doc level for DisplayedAttributesDateFormat (the default (empty string) inherits the Doc Settings’ value. Note, you can set $DisplayedAttributesDateFormat at note level (like any other attribute) although all displayed Date attributes use the same format in any given note—whether customised or set at document level. If you want dates displaying in ISO 8601 outside edit mode, use date format string “
=”, or the same but without the time and timezone info use “==”. - Time. If you add a date, regardless of format, with to time element, Tinderbox uses the current macOS system time†. But, you can either a space a ‘hh:mm:ss’, e.g. "
14:23:05" or “00:00:00” or use the time(aDate, hoursNum, minutesNum[, secondsNum]) operator to set a time of your choice (see link for a code example).
I’d also clarify, having had to check, that using date(dateStr) with an ISO 8601 format string will work‡ when creating Date-type data in action code, though date(yearNum, monthNum, dayNum[, hourNum, minNum]) might be as easy to use.
Tinderbox, at time of writing, does not have any understanding Extended Date/Time Format (EDTF) Specification modification to the default forms of ISO 86021. Therefore, EDTF should not be used fore Date-type data work. Users may choose to EDTF ‘manually’ in String-type stored data but that will require the user to parse the meaning, i.e. be reading the stored string by eye in the UI.
I’ve made a note to self to, after current travels, review aTbRef articles on date() and Date-type format attributes to clarify support for ISI 8601 as an input format for Displayed Attributes or date(). Separately, I’ll add a not on partial dates clarifying that the are not supporting is Date-type data and suggesting a few of the String based workarounds already discussed above.
†. Why? Because ‘Date’ type data is actually stored as a number of milliseconds from a reference date. So a Date has no notion of a date without time. What you see on screen is that number of milliseconds rendered into a human readable string of text.
‡. Actually this got added way back in v4.5.0.