Writing a system Extension

[Scott Squires]

I was actually leaning toward reusing some of the dates prior to 1984 since it's impossible for any timestamps to actually occur before the mac itself.

It's the opposite of impossible. It happens all the time. Any database, spreadsheet, accounting ledger, library catalog, etc. will have the need to store timestamps before 1984.

The Gregorian Calendar repeats itself every 28 years, so it might be easiest to simply set the clock back to the earliest compatible calendar year prior to 1984, and then hack the display routines to add however many years to the system year to make it display the current year whenever it encounters a date that occurs before 1984.

I read this sentence several times but still don't understand it. Why would you want all years before your new epoch to appear as the current year?

 

[jamie marchant]

I don't know that much about the inner workings of the Classic Mac OS but is there no universal place that one could patch the time mechanism. 


Also I think Denodster was talking about the date stamp on files in which case he is correct. 

 

[denodster]

It's the opposite of impossible. It happens all the time. Any database, spreadsheet, accounting ledger, library catalog, etc. will have the need to store timestamps before 1984.

I was talking about file timestamps specifically its impossible for a file created on a mac to have an actual creation date prior to 1984. If I have any scrap of success it's obviously going to be a hack and have downsides, so if someone is using an LC to keep track of an accounting ledger in the year 2040 they can weigh it as an option.

I read this sentence several times but still don't understand it. Why would you want all years before your new epoch to appear as the current year?

I'm leaning away from moving the epoch, because it would cause a lot of problems with existing data. Instead, the idea is to repurpose dates between 1904 and 1984 to represent 2016 through 2096 since the calendars for said year ranges are the same. obviously this has it's own set of problems but its just an idea at the moment.

 

[Scott Squires]

I don't know that much about the inner workings of the Classic Mac OS but is there no universal place that one could patch the time mechanism.

In theory, yes there is a single official place one could patch. In practice, programmers have things they want to do that aren't possible or are less efficient with the api functions. Or they think they have a better way. Or they just do it their own way because they can, they have an ego, or they don't know any better. The end result is that applications use the api functions some of the time and do their own thing at other times. It's the resulting mix of using the official (patched) api and their own code that will cause havoc.

Also I think Denodster was talking about the date stamp on files in which case he is correct.

There isn't separate date and time code for file timestamps. It's all the same code. Well, unless it's combined with custom code as above. Which would not be surprising.

I'm leaning away from moving the epoch, because it would cause a lot of problems with existing data. Instead, the idea is to repurpose dates between 1904 and 1984 to represent 2016 through 2096 since the calendars for said year ranges are the same. obviously this has it's own set of problems but its just an idea at the moment.

OK, that's what I was expecting your reasoning to be when I started reading your description, but I couldn't figure out how to align that with what you wrote. This is a much better explanation.

I was talking about file timestamps specifically its impossible for a file created on a mac to have an actual creation date prior to 1984. If I have any scrap of success it's obviously going to be a hack and have downsides, so if someone is using an LC to keep track of an accounting ledger in the year 2040 they can weigh it as an option.

Yeah. Some people might just want to have filesystem dates correct. Users can make their own choice as long as it is made clear what the change is, that it is mainly intended for filesystem dates, and that it could really confuse application date handling.