Well, technically there’s also no year 1 or any years before 1582 in the Gregorian calendar (when it started use). That’s why the Proleptic Gregorian Calendar was invented (otherwise known as international standard ISO 8601), which does have a year zero, and it’s a leap year
http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
But I think you’re right in that there’s no year “0” in AppleScript.
Originally, I thought that the year “wrapped-around” from 9999 to 0000, but now I see that year “1/1/0000” is actually equivalent to “1/1/10000”
So the range of dates that AppleScript can be made to display is more like
1/1/0001 12:00:00 AM BC thru 1/1/0001 12:00:00 AM AD thru 12/31/9999 11:59:59 PM thru 12/31/0000 11:59:59 PM (using a 12HR US Time format)
But, clearly AppleScript (under the hood) is capable of storing dates well beyond those limits. Based on my tests, it allows advancement of up to 9.223372096907E+18 seconds from 1/1/0001 and subtraction of up to -9.223371976802E+18 seconds from it as well. That would yield a data range spanning somewhere around 584 Billion Years!
Of course, AppleScript can only store about 15 significant digits in a number, so that limits the fully accessible date range to around 63 Million Years! (wherein every second can be specifically addressed)
But, in practice the limit is even lower, because AppleScript will only let you set the year property of a date to as low as 0 (1 BC, though it reports that as year 0001) and to a maximum of year 32,767 (or 2^15 - 1).
And finally, it’s possible to demonstrate a failure in AppleScript’s date formula above year 29,940.
set {x, x's day, x's month, x's year} to {current date, 31, 12, 29940}
set {x's hours, x's minutes, x's seconds} to {0, 0, 0}
return x --> date "Tuesday, December 31, 9940 12:00:00 AM"
The above works fine (other than the year is reported as 9,940 instead of 29,940), But, one year higher and it all falls apart:
set {x, x's day, x's month, x's year} to {current date, 1, 1, 29941}
set {x's hours, x's minutes, x's seconds} to {0, 0, 0}
return x --> date "Friday, January 1, 1904 12:00:00 AM"
So as near as I can determine, AppleScript appears to be (at least on my G5 Mac) capable of directly addressing date properties (down to the second) for every date between 1 BC thru 29,940 AD as well as making use of those values in meaningful calculations. Though, as we all know, it can only display the last four digits of any year above 9,999. And it’s then simple to create a handler for coercing such a date into a string with the correct year:
set {x, x's day, x's month, x's year} to {current date, 23, 1, 12345}
set {x's hours, x's minutes, x's seconds} to {4, 56, 12}
return x --> Returns: date "Tuesday, January 23, 2345 4:56:12 AM"
on getDateTimeString(x)
set {w, m, d, y, t} to {x's weekday, x's month, x's day, x's year, x's time string}
return (w & ", " & m & " " & d & ", " & y & " " & t) as string
end getDateTimeString
return getDateTimeString(x) --> Returns: "Tuesday, January 23, 12345 4:56:12 AM"
One final way to demonstrate this (mainly for fun) is to calculate the average year length for all years within the acceptible range:
set {y1, y2} to {0, 29940} -- From 1/1/1-BC to 1/1/29940-AD
set {x1, x1's day, x1's month, x1's year} to {current date, 1, 1, y1}
set {x1's hours, x1's minutes, x1's seconds} to {0, 0, 0}
set {x2, x2's day, x2's month, x2's year} to {current date, 1, 1, y2}
set {x2's hours, x2's minutes, x2's seconds} to {0, 0, 0}
return (x2 - x1) / days / (y2 - y1) --> Result: 365.24248496994 days per year
The Gregorian calendar repeats every 400 years, so if you change the range to {0, 400} or {400, 800} etc. it returns exactly 365.2425. Which completely agrees with the average Gregorian year length.
Using dates beyond the range (0-299940) causes that AppleScript calculation to fail.
So, that’s about as crazy as I want to get with all this. It’s making my head hurt now…but it was still fun!