Where is the 12:03:58 AM coming from ?
set dateString to "300573"
set dateReference to makeDateReference(dateString)
-- date "Tuesday, May 30, 73 at 12:03:58 AM"
on makeDateReference(myDateString)
local tempDate
set tempDate to (current date)
set tempDate's year to myDateString's text 5 thru 6
set tempDate's month to myDateString's text 3 thru 4
set tempDate's day to myDateString's text 1 thru 2
set tempDate's time to 0
return tempDate
end makeDateReference
I guess it helps if they weren’t born in the year 73…
on makeDateReference(myDateString)
local tempDate
set tempDate to (current date)
set tempDate’s year to (1900 + (myDateString’s text 5 thru 6))
set tempDate’s month to myDateString’s text 3 thru 4
set tempDate’s day to myDateString’s text 1 thru 2
set tempDate’s time to 0
return tempDate
end makeDateReference
Hi adayzdone.
There’s been a bug for the past few system versions whereby the text representations of very early dates are a multiple of 75 seconds out from the other properties of the date objects. (It’s the other properties which are right.) The further west you are, the greater the error. The year of your date is 73, so I’d expect the bug to manifest, but in your part of the world, you should theoretically be getting date “Monday, May 29, 73 at 11:52:30 pm”. 
When I run the posted script here in France, with Yosemite 10.10.2 running in French, I get :
date “mardi 30 mai 73 00:00:00”
which is the correct result.
Yvan KOENIG (VALLAURIS, France) jeudi 12 février 2015 21:17:54
Well here it’s 1895, so not so very early 
I presume it relates to the official adoption date of current GMT-relative time zones. Here, that happened on February 1, 1895 – we moved from time based on capital city observatory offsets to standard meridian offsets.
That doesn’t seem to be the case here: date “Monday, 29 May 73 11:39:52 pm”. I presume the value is based on the difference between the before and after time zone offsets.
Hmm. I either misinterpreted or misremembered previous exchanges on the subject or the bug has mutated again under Yosemite, which is equally possible. It doesn’t seem to affect France, Brazil, or Greenland and the New York date text seems to be ahead rather than behind. Either way, it’s a bug. The date as text should match the date, regardless of the official adoption of time zones past or present. (And local adoption of a time zone can’t be considered a good enough excuse when the year predates even the European colonisation of Australia! ;))
Here in the UK, the crunch date is near the end of 1847. date “Wednesday 1 December 1847 00:01:15” is correct, one second earlier is rendered as date “Tuesday 30 November 1847 23:59:59”, regardless of the British or Irish city chosen in System Preferences’s Time Zone panel.
As far as I’ve been able to determine, the other, non-text properties of AS dates are reliable over the whole of the original official AS date range (1/1/1000 00:00:00 to 31/12/9999 23:59:59) and right down to 1/1/0001 00:00:00 AD. Beyond that, the year property goes down to 0, -1 etc., although the text versions do in fact show the correct BC years!
tell (current date)
set its year to 1
set its month to 1
set its day to 1
set its time to 0
tell (it - days) to return {its year, its month, its day, its time, it}
--> {0, December, 31, 0, date "Saturday 30 December 1 23:58:45"}
end tell
No question. If you modify the medium time string in System Preferences to show the time zone, you’ll see the offset there changes by the same amount. Which is a bit odd, because more recent dates show the current offset including daylight savings based on whether daylight savings is active now, and not on the actual date.
Anyway, all these dates are presumably built on top of NSDate, so you might find this interesting reading:
359north.com/blog/2015/02/08/the-limits-of-nsdate-and-friends/