Actually even more interesting. I just tried on my mavericks machine a
```
touch -t 205012121212 foobar
```
to create a file with timestamp that far in the future. `ls -la` back gives `Dec 12 2050 foobar` as expected. So the situation is more intriguing than I thought, even though HFS+ doesn't support it, the system is still somehow dealing with it correctly. Anyone got any clues as to how that's even possible, or if I'm missing something obvious?
Edit: Still doesn't make sense, based on
https://github.com/apple-open-sourc...96d7297069bf84d42b30d3c/hfs/core/MacOSStubs.c any time that wraps around should be returned as a unix epoch when converting from hfs time to bsd time. Maybe there is some caching going on at the kernel layer which is thus bypassing hfs entirely?
Edit 2: Haha yes got it! It was indeed caching. Do this on a removable media, then when you remount date gets reset to Dec 31 1969 as you expect. And just eyeballing it, the fix to patch the HFS layer is really simple, just update the 2 functions to convert between hfs time and bsd time. From what I can see the source is relatively complete and includes compression, but worst case we can even just hotpatch the kernel. We can reallocate the [1904, 1970) range to representing [2040, 2106) and beyond that everyone on this forum will be dead so we don't have to worry about it. The only downside is that if you use the HFS drive with another machine which doesn't have the patch installed, the date will get reset to unix epoch. But that's the best we can hope for anyway. Someone needs to update that stackexchange answer, it is wholly incorrect on all levels. I also find it amusing that apple knew that hfs timestamps before 1970 epoch couldn't be represented in unix anyway, but for some reason decided to just throw away that extra headroom instead of reallocating it.
That will only leave fixing the rest of userspace.
@Amethyst1 what happens if you set the date via terminal instead of syspref? (via unix date command)
