Robin wrote:
>?Ronald J Kimball <[EMAIL PROTECTED]>wrote:
>>Do not subtract 100 from the year returned by localtime!
>>Apparently some programmers have a very short memory
>>Unless you want your script to fail for years before 2000 and after 2999
>
>on a purely programmatical basis, using the modulus just didn't occur to
>me, thanks for pointing it out.
>
><tongue in cheek>
>on a purely philosphical basis even supposing my pathetic script for
>stamping update info on web pages, which didn't exist before september
>2000, lasted without revision until after 2038 (unix) and 15th Feb at
>06:28:18 2040 (Mac), unless there are some changes made in the interim,
>even with your suggestion, my script would fail :-).
></tongue in cheek>
The Macintosh date issues were solved in the late 1980s, for developers who
elected to use the new 64-bit signed date value. [The Mac OS will deal
with windowing the 32 bit clock into that. In about 2010, the meaning of
the two bit year 99 will change in Mac OS...it already did so back in the
late 1980s if one set one's clock ahead a little.] Carbon apps by
definition use the new stuff: the old stuff isn't in Carbon. AppleScript
has always (defined as since public release) used the 64 bit version.
The Unix issues will be solved well before 2038.
Meanwhile, it's probably safest to use the published definition of the year
slot:
year - 1900
Taken literally that will last a long time (longer than any warranty I
issue ;-)), even if integers don't grow in the meantime. So, add 1900 to
the value in the year slot and go from there.
--John
--
John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA
