Looking for the document "Macintosh Worldwide Development: Guide to System Software"

[David Cook]

I've been researching the Apple system routines that use LongDateTime as part of a potential solution to the 2040 problem. Because it is first documented in Inside Macintosh Vol VI, I assumed that those routines first appeared in System 7. But, on closer inspection and with some testing, those routines seem to first appear in System 6.0.

There is a big gap between the year that Inside Macintosh Vol V was published (1986) and Vol VI (1991). During that gap, other documents reveal the routines and features added in the meantime.

I am looking for a copy of "Macintosh Worldwide Development: Guide to System Software", which apparently covers the ScriptUtil during the period that LongDateTime was introduced.

I'd appreciate any help locating a copy,

David

 

[Trash80toHP_Mini]

Has anyone archived the Developer CD series online? All the ones I have are from later in the '90's so I can't help.

 

[adespoton]

The Developer CD series is on MG, but that starts in 1991 with Phil & Dave's Excellent CD. It pretty much coincides with the publication of Inside Macintosh Vol VI.

Although... has anyone checked to see if there's a copy of the Guide to System Software on that CD? I don't have mine handy, but I seem to recall it containing documentation going back to 1989 at least.

 

[David Cook]

Here is what I’ve learned. Unless noted otherwise, all of this information is based on System 6.0.0 and Inside Macintosh Operating System Utilities. It may have changed in later systems, particularly when PowerPC came along.

1. LongDate2Secs (aka LongDateToSeconds) and LongSecs2Date (aka LongSecondsToDate) were added in System 6.0. They do not exist in System 4.3 (aka System Software 5.1)
2. In System 6.0 specifically, those routines are located in the System file, resource ‘INIT’ id 2 (@ 158E and 1754 respectively). That’s anon 51 & 54 in ResEdit; anon 21 & 23 in Resorcerer. This code moved to 'ptch' 4 in System 6.0.2 and 6.0.5. I did not check other systems. Searching for the hex sequence 2F3C00023AB1 usually finds it.
3. In System 6.0 and some other systems, at the ends of the routines are some old style (?) Macsbug symbols. For example, at offset 18EC, you’ll find the name of LongSecs2Date as the slightly cheeky “LSEX2DAT”. These symbols should help you track down other routines.
4. Based on some quick tests (running System 8.1), despite implying otherwise in Inside Macintosh, LongDateRec only uses a portion of the fields when calculating LongDate2Secs. Specifically, it uses era, year, month, day, hour, minute, and second. The dayOfWeek, dayOfYear, weekOfYear, and pm are all ignored as inputs to that routine. Those fields do not need to be initialized per List 4-7 on page 4-16. This makes sense, as some of those fields could contradict other fields. For example, List 4-7 initializes dayOfYear=1 when clearly July 4 is not the first day. It also sets PM=1 but the text below says correctly that the returned value is AM. Why not just initialize PM to 0?
5. Page 4-5 is wrong about some field ranges. dayOfYear can go to 366 and weekOfYear can go to 53. For example, Dec 31, 2020. LongSecs2Date works correctly for that date.
6. 0xCDFFFFFFFF is the most positive seconds you can pass to LongSecs2Date. It results in January 11, 29941 AD. Inside Macintosh incorrectly claims the maximum year is 29940 AD. Passing 0xCE00000000 results in January 1, 1904 – intentionally. That is, there is code that checks for the limit and clears out the seconds before continuing.
7. 0xFFFFFF1500000000 is the most negative seconds you can pass to LongSecs2Date. It results in January 3, 30081 BC. Passing the more negative 0xFFFFFF14FFFFFF results in January 1, 1904 – again intentionally.
8. These limits on the year seem arbitrary; likely rough approximations of the limit on the year field (two bytes signed) which can go to +32767.
9. As documented, year zero is handled in the Anno Domini system, meaning 1 BC. I have not found documentation as to how 64-bit timestamps in Unix or C handle year zero. My guess is that they follow the astronomical conventions of including 0. But this is really too far down the rabbit hole, as I can’t imagine any vintage software used Apple’s LongDateTime to hold archeological data.
10. For completeness, the era field is -1 for BC and 0 for AD. Negative years results in an off-by-one result. See 4-26 and 4-27. This is dumb. They could have used negative years for BC and dropped the era field to make LongDateRec backward compatible with DateTimeRec. They also could have followed the naming convention and called it LongDateTimeRec. C'est la vie,
11. The field, weekOfYear, follows the convention that Sunday is the first day of the week. So, if the first day of the year is Saturday, that is week 1 (a partial week). Then, the next day (Sunday) is week 2 (a full week).

Based on this, it would be possible to standardize on LongDateTime and LongDateRec for a 64-bit time patch. One could copy the routines out of the System file and include them in glue code or an init that patches _ScriptUtil (trap A8B5). I will try back-porting them to System 0.97 and see if they work on a Macintosh 128K. That trap is undefined (hopefully unused) on the 64K ROMs.

 

[David Cook]

Has anyone archived the Developer CD series online? All the ones I have are from later in the '90's so I can't help.

The Developer CD series is on MG, but that starts in 1991 with Phil & Dave's Excellent CD. It pretty much coincides with the publication of Inside Macintosh Vol VI.

Although... has anyone checked to see if there's a copy of the Guide to System Software on that CD? I don't have mine handy, but I seem to recall it containing documentation going back to 1989 at least.

Thank you. I'll look.