Is there a way to change the format of the way a date is presented for a date attribute?
Specifically I want to show the year as four digits and not two for Start Date and End Date.
My expectation is that there a setting for changing the way a date presents.
Based on what?
I think this this due to the Apple US locale macOS defaults, from which Tinderbox inherits. On my UK-locale system, I see a 4-digit year:
Have you checked: mac OS settings for correct settings?
Thanks Mark:
I didnât think about the OS. When I looked at system preferences I see the option to define a short, medium and long form of the date but I donât see a selection for something like preferred.
In general terms I would expect the OS to give the application control of the presentation of the date, if the date is an important parameter.
Based on what?
Based on 35 years of using a Mac. Seriously I do have an expectation as noted above that where dates are important then in general terms their presentation would be controlled within the application.
My guess is that if you donât know of a tweak within Tinderbox to change this format then there isnât one.
thanks for looking.
Also, see $DisplayedAttributesDateFormat, which is probably what you were looking for.
Thanks.
FYI: I couldnât find that panel and so I did some experiments.
Ended up setting $DisplayedAttributesDateFormat to âm/yâ. This produces a displayed date of â1/1960â
That panel has been there since v6. What version of Tinderbox are you using?
Use menu Edit â Document Settings⌠or â+8 to open the Document settings dialog. In that dialog, click the Text button in the top toolbar. That swirched the dilaog to this tab:
The âDisplayed Attributes Datesâ sets the attribute DisplayedAttributesDateFormat to one of three presets. If not happy with any of those choicxes, use Cmd+1 to open the Inspector
Sorry hit the wrong button, but carrying onâŚ
On the Inspector click the System sub-bab. Now use the top (search) input box and type âDisplayedAttributesDateFormatâ (no enclosing quotes) and press the Return key. The result will look like this:
Type your desired format string into the Default input box (no quotes) and press the Return key. Now _all Date-type attributes in the Displayed Attributes or Get Info/attributes tables will be displayed using your desired date format.
If you are unable to follow these instructions, please report your OS version and app version.
Answer: V9
The problem is me being lost in a sea of choices. So I appreciate you pointing me in the correct direction.
No worries. Choice is confusing. Bear in mind though that Tinderbox is essentially a toolbox where you pick some of the tools from the box as pertinent to your task. So not everyone uses the same tools for the same task. Even for the same task people do things in quite idiosyncratic waysâwhich is good.
Think âthe task Iâm trying to doâ not âthe application Iâm more used to using does this differentlyâ. 
New question prompted by preceding dialog hereâŚ
I would like Tbx to allow me to input Event dates and display them in Year-Month-Day format (as in 19431102, 1943-11-2, or 1943/11/2 syntax. The year-month-day order is the important part.
Iâve navigated through the Document Inspector to the System panel and the âDisplayedAttributesDateFormatâ âDefaultâ entry window. What is the syntax for the string I should enter into the âDefaultâ window to direct Tbx to use a â1943-11-2â date format?
Thanks!
Wearing my hat as a former historian I would say there is value in defining oneâs own user attributes for dates. I had one for eventYear one for eventMonth and one for eventDay. I also had one that I could set to âcircaâ or âbeforeâ or whatever. This meant that I could set some things as happening in a year and not worry about the rest of the date. One of the most annoying things about using Tinderboxâs own Date attribute was that it would put in a time as well as date, which I rarely wanted. Breaking the date into components also gave me some flexibility further down the line.
@Sherrell see this reference sheet, and use this:
or y-M0-d if you do not want day-of-week zero-padded.
Iâm busy with other things today, so Iâll have to check this another time. However, for working in history Iâve always found it essential to roll my own. Information can be vague or incomplete, and Iâve needed to accommodate that. When you have âborn about 1756â or âwe started our work in the summer of 1942â then conventional date formats just wonât do. Apart from anything else, it is useful to be able to see when you donât know the exact date that something occurred. Rolling your own gives you much more flexibility.
Youâre right. Sorry for the assumption.
Paul: Tks! Now I understand how to use the information in Appendix 5 of the Tbx Userâs Manual. I knew Tbx could handle ISO-8601 date formats - just not how to enter it.
Martin: Everyone is an historian. Some people (we call them Historians) just are paid for being one. (SMILE)
I agree with you observations about dating flexibility. The ability to employ fuzzy dates is an essential capability. In fact, I have a 230 event timeline Iâve built there as a starting point for this project. The ability to conveniently define âArcsâ in conjunction with ATâs âSubwayâ view is a powerful way to visualize relationships between events.
My Workhorses for this project are DEVONThinkPro, Aeon Timeline, (currently) Zotero (but Iâm still evaluating whether to switch to Bookends), Scrivener, and Tinderbox. I have the most experience with Scrivener and DTP. Probably Zotero after that. My heavy lift is learning enough to use effectively use all these tools. My major TBDs are: (1) how best to capture Event/Timeline information to analyze and display and the workflow between AT and Tbx to do that, and (2) how best capture references and citations (Zotero or Bookends) along with the workflow between Zotero (or Bookends) and Tbx.
The point raised about âfuzzyâ (incomplete) dates get to the heart of this. We, without stopping to consider, happily chop between proximate âdiaryââ time where date/time down to the minute and second may matter so warrants consideration, versus broader âhistoricalââ times. Do we need to know the state of the tide when Julius Caesar disembarked in Kent to conquer the Britons? The day would be nice but at this distance a year (if known!) would suffice. But, if planning to attend the upcoming departmental meeting nexts a finer granularity than ânext weekâ.
Although humans happily chop between these two, code has no such choice. Plus, the two shade into one another. The boundary is subjective. Where âthe pastâ starts will differ for an 80-year-old compared to a 20-year-old.
Tinderbox Date-type attributes are essentially a Date/Time attribute. Indeed, in early documentation they were called that. They canât not store a time element. Why? because how they work is they store a numberâthe number milliseconds from a fixed point âĄâand use that to work out the appropriate date/time.
Tinderbox provides date formatting codes (as @PaulWalters noted previously) such that the label we see on screen representing a date/time might appear as â44 BCEâ not â1 Jan 44 BCE 00:00:01â, or such.
âToo complicatedâ, we cry, âthe app should, nay must, just figure this out for usâ. If only. For the app to do that weâd need to signal out intent, but thatâs intuitive to us so we find it hard to articulate ⌠and anyway why canât the software just guess correctly for us? Plus, the app is a toolset not a per-build limited-scope process.
So what are the pragmatic choices available?
Donât use Date-type is you donât need to. You need Date-type data to use timeline view and to do Date-based arithmetic. But if you donât require either/both those then you might just be better off using a string to hold a date (eq.v. system attribute $PublicationYear is not a Date as it only ever holds a string with the year of publication).
As regards fuzzy/partial dates, you canât store a Date-type of âFebruary 1425â as there must be a day and time if not given is normally auto-added as system time of day at point if edit. So if you need to use dates, and for some to be missing day or month, it is a good idea to decide on a day/month to use as a default (1 on month vs. end or middle, January vs July, etc.) , record that in your TBX (as youâll forget) and use that rubric when setting in complete date-type dates.
You can have both if you want, a date type date for use in, for instance, timeline and a string for general use. But again, do note this as if you change one youâll need to change the other. The app canât always guess and even then having code constantly look for occasional manual edits is poor use of automation.
Another aspect of fuzzy dates is you donât have to use just the system $StartDate & $EndDate. You could, add a $NotBeforeDate and $NotAfterDate you give flex for start end. Or, more complex, a $NotStartBefore, $NotStartAfter, $NotEndBefore, NotEndDafter. But, this is an exercise for us the user. If we know weâll do the same in several projects, make a âstubâ document with lots of the customisation pre-done, then for a new projects, copy the stub and use the copy as your project document.
I point to note, is that as the user, you are in charge so make and implement the decisions (within the available toolbox of features).
So whilst doing all the other âsandboxâ trials, for a historical project consider what is useful to you in terms of how dates and their many and varied oddities are best annotated in your project going forward.
If looking for help in this it is generally better to ask âIâm planning to do X, does this make sense?â rather than as tends to happen âIs anyone doing X?â Even if they are, likely it is slightly different from your needs, so itâs better to ask form the context of oneâs own work. Itâs rare somebody has done exactly the same before. But lots of different people may have don similar parts of the whole, albeit in a different context.
HTH
â . The terms/distinctions are mineâdoubtless there may be established terms for this of which Iâm unaware. Please correct me if so!
âĄ. From the Unix epoch, if memory serves. But, for almost all of use such underlying detail is moot. A Date/time is a number based on a fixed reference date/time.
Wow, Mark. Thatâs a lot there to digest. Thank you for the detailed tutorial and perspectiveâŚ
Sherrell
Yes, there is a lot. no need to digest immediately. Just there for when it/if becomes pertinent.
