Tinderbox Date data and timezone offsets

Tinderbox Tasks
21

(Not sure if invoking osacript -e “…” with runCommand would work - I haven’t tried)

Yes, I used to do that before Tinderbox became scriptable. Fussy because of the need to escape for the shell. Could never get scripts containing single straight quotes to work. Also little gotchas like having to trim the final character for a URL attribute to be active in Tinderbox. Haven’t tried with dates.

Old notes and a simple example

General format in runCommand()

osascript -e followed by a space followed by the script surrounded by single quotes followed by a space followed by the first attribute surrounded by singlestraightquotes followed by a space followed by the second attribute surrounded by singlestraightquotes, etc.

Example:

In a stamp:

$URL=runCommand(“osascript -e '” +$Text(“GetMaillinkAS”) +" '");$URL=$URL.substr(0,($URL.size-1))

In a note named GetMaillinkAS:

tell application "Mail"
	set theselection to selection
	if length of theselection is not 1 then
		display dialog "Oops. Select ONE message in Apple Mail and then try again." buttons {"OK"} default button 1
	else
		set the selectedMessage to item 1 of the theselection
		--for Tinderbox URL attribute wrap the id with %3C and %3E
		set messageURL to "message://%3C" & (message id of selectedMessage) & "%3E"
	end if
end tell
return messageURL
1 Like
22

Reading between the lines of the section on dates in The Tinderbox Way incidentally, I think that the pattern of writing timezones out to .tbx XML, but not reading them back in, may be by (current) design.

(It seems that the approach to dates has changed over time, under pressure from issues like comparability – when are two dates or dateTimes ‘equal’ ? – and symptoms of jet-lag)

1 Like
23

Gave this a rest since it’s confusing, and now have just revisited.

Surely it cannot be by design for Tinderbox to change a point in time!

Enter in NY TZ as “3/1/19 1:00 AM”

”2019-03-01T01:00:00-04:00"

Close doc, switch to Taipei TZ:

“2019-03-01T01:00:00+08:00”

Switch back to NY TZ without closing:

“2019-02-28T12:00:00-04:00”

And date is now displayed as:

“2/28/19, 12:00 PM”

Compared with what was originally entered (with the user having made no changes other than let the machine switch time zones and then switch back to the original time zone) one ends up with a different date, a different point in time!

Would be much more comfortable if the date string representing the original point in time didn’t change from what it was when the date was last entered/modified by the user. And if there is a reason it simply must change, then it should change to something that represents the same point in time.

24

The next backstage build will change the way Tinderbox reads dates from its XML files, and the way is parses ISO-8601 dates like “2019-02-28T12:00:00-04:00”.

Currently: when reading documents, Tinderbox assumes that times were saved in the current local timezone.

Future: on macOS 10.12 and later, Tinderbox will respect the time zone of the date in saved documents, and will also recognize the time zone when assigning an ISO8601 date string to a date attribute. On 10.10 and 10.11, the old behavior will be retained.

2 Likes