Quote:


To clarify, which original date do you want to use for the sorting?
  - The date when the Tinderbox note itself was originally made? Or
  - The date that the clipping / item was originally made?

That is, if you make a note on January 1, 2010, of a newspaper item published July 1, 2009, which are you looking for as the sorting date?

 If you want to sort on the date when the Tinderbox note was created, fortunately that's easy! When you create a note, an attribute called $Created registers that date and time, and doesn't change.

But if you want to register the newspaper item's date, then you just enter it. Create some attribute called (say) $PublicationDate; enter the date you want; and there is no reason why that should change on its own later on.

I am sure the gurus will straighten me out if I've missed this. But what you're asking should be easy to do.

As to @agl's closing question, although all (most!) of us each use dates in one format, there are many formats (more than you'd think). The most obvious difference is the order of day and month. For example, month comes first in the USA, the day first pretty much everywhere else. Though a forward slash seems the most popular segment divider (23/8/02) some countries use full stops (23.8.02) or hyphens (23-8-02).

Thus when you type "Sun 2 August 2015" into a Date-type input box, for instance $StartDate, TB will hope for something in one of your localised date settings. From your sign-off up-thread it looks like you're in UK, like me, so in OS X System Preferences you date formats will probably look like this:



Look carefully at the last row - 'Full:' and notice the comma. If I enter "Sun 2 August 2015" in $StartDate I get "30/08/2015 10:27". But, if I add in the comma used in the 'Full' format e.g. "Sun, 2 August 2015"  then in $StartDate I get "02/08/2015 12:00". Note the time element in the latter - on which I'll comment on further below. If I change 'Sun' to 'Sunday', even with the comma, the parsing breaks again as we're not following a 'known' format and Tinderbox is effectively having to guess our meaning. 'Sun 2' or 'Sunday' coerced to a number seems to give 30, whict TB gets the month and year parts correct.
Edited:

The example above is based on UK settings. Were I in the US, I might get different results: consider that 6/7/2015 is 7th of June 2015 in the US and the 6th of July elsewhere. You should endeavour to give Tinderbox a date input using formats those defined in your OS locale's data formats. Otherwise, the app will do it's best to guess and - as in the opening setting - sometimes make mistakes.

Time. The OS date formats don't specify a time pre se, although the same panel does define your locale's time format. Here in UK a colon delimits hours, minutes and seconds (12:40:35) - elsewhere it might be something different like a full stop (12.40.35). If you give Tinderbox a valid date but no time element, Tinderbox will append your current system time in h:m:s (though only h:m are displayed) formatted in your locale's time format.

In testing for this answer, I've noticed an oddity re use of the 'Full' date format without a time portion. If I enter "Sun, 2 August 2015" - no time - I get "02/08/2015 12:00" even though the current time is not 12:00. If I input with a time e.g. "Sun, 2 August 2015 10:51" I get "02/08/2015 10:51"

Note that from v6.3.1 you can alter how Date-type attributes display in Key Attributes via $KeyAttributesDateFormat.

I think that's proably enough Date-type trivia to chew on for now.  

I'd suggest setting the OS short format back to the default and trying out $KeyAttributesDateFormat. You'd use the same format string as used in your export template. For better or worse, Tinderbox seems to cope best figuring dates from text input - such as in key attributes - if you use the (default for your locale) OS 'Short' format. In fairness, dates are far more complex to 'guess' from parsing than perhaps imagined - so many small edge cases, especially when you factor in users in different languages.