Thanks for the explanations.
“converted automatically to the time zone to which the Mac was set"
Could perhaps have been more fully expressed as follows.
"When a date-time is entered into a date attribute in Tinderbox that point in time is represented by an ISO string containing the local date and time in the time zone to which the Mac is set at the time of entry with an appended offset from that original time zone to UTC.
When the time zone setting on the Mac is changed, Tinderbox automatically changes the original ISO string to express the same point in time as the local date and time in the time zone to which the Mac is now set with an appended offset from the new local time zone to UTC."
Converting the old and new ISO date strings to UTC, either via a library or in AppleScript via a simple handler like the one above, as demonstrated, shows that Tinderbox does the right thing and the two different strings represent the same point in time.
The practical problem that I’ve encountered is this. Working with the “new” ISO string that Tinderbox automatically generates to replace the original one, how does one, for a series of historical dates, get back to the original local date-time in the original time zone? If one knows the time zone offset for the original time zone (and knows how to retrieve the “new” time zone offset from the new ISO string, as in the handler posted above), basic AppleScript time arithmetic quite easily gives the answer, without having to make a trek to the library.
But, but … what about summer time? For a series of historical dates it’s sometimes observed in one time zone but not in the other, messing up the arithmetic. Do the libraries automatically account for that? See the edit to my post above to include an old reference to JavaScript that suggests, sadly, that summer time “must be deal with manually.” Is that still the case for JavaScript? Is it also the case for the “NS classes”?