Saturday, January 4, 2020

TenFourFox FPR18 available (and the classic MacOS hits Y2K20)

TenFourFox Feature Parity Release 18 final is now available for testing (downloads, hashes, release notes). There are no other changes from the beta other than to update the usual certs and such. As usual, assuming no late-breaking critical bugs, it will become final Monday evening Pacific time.

Meanwhile, happy new year: classic Mac systems prior to Mac OS 9 are now hit by the Y2K20 bug, where you cannot manually use the Date and Time Control Panel to set the clock to years beyond 2019 (see also Apple Technote TN1049). This does not affect any version of MacOS 9 nor Classic on OS X, and even affected versions of the classic MacOS can still maintain the correct date until February 6, 2040 at 6:28:15 AM when the unsigned 32-bit date overflows. If you need to set the date on an older system or 68K Mac, you can either use a CDEV like Network Time, which lets you sync to a network time source or a local server if you have one configured (as I do), or you can use Rob Braun's SetDate, which allows you to manually enter a date or time through the entire supported range (and even supports System 6).

One other note is that all HFS+ volumes regardless of operating system version have the same year 2040 limit on dates -- that includes Intel Macs using HFS+ filesystems. You have 20 years to think about how you want to fix this (during which you should replace the PRAM batteries in your classic Macs, too).

at

5 comments:

  1. ClassicHasClassJanuary 5, 2020 at 5:02 PM

    Was this after restarting the browser?

    I haven't tested the situation where r.p-o-l.e and t.r.f-e are both false, because I've never shipped it with the former set false. However, it should go back to the previous shipping behaviour if t.r.f-e is false, and I did test that.

    ReplyDelete
  2. AnonymousJanuary 6, 2020 at 8:31 AM

    [ChrisT.] What's your setting for reader.parse-on-load.force-enabled?

    ReplyDelete
  3. ClassicHasClassJanuary 6, 2020 at 8:10 PM

    I'm able to reproduce it, but I'm not holding the release since the browser has never been shipped that way (nothing personal). A fix should be straightforward for the next version.

    ReplyDelete
  4. kpJanuary 7, 2020 at 5:26 AM

    No problems to report on final. It seemed peppy loading . . .

    ReplyDelete
  5. artphotodudeFebruary 15, 2020 at 11:38 AM

    I think the simplest way to deal with this is to find an analog of the actual date with a previous year - So an earlier Leap Year with Friday the 29th of February, and then have a thin translation layer that displays the actual, impossible date. File creation/modify dates will be wrong, but in the grander scheme of things this will not matter.

    ReplyDelete

Due to an increased frequency of spam, comments are now subject to moderation.