As long as you never convert far future dates into a timestamp you should be fine. To save such dates as timestamps you’d need to subtract out the 930 years before conversion to a timestamp. So it becomes a string manipulation exercise to extract the year portion of dates and adjust accordingly. I’m assuming you have no need to manage current dates as well as future dates. My suggestion only works if you can unequivocally convert all dates all the time. Also that no dates after subtracting out the 930 are later than early 2038.
If there is some specific issue I’m missing, let me know and I’ll try to come up with something.
Correct, all dates can be future dates. Trouble is, all dates are after 2038. (It’s a fictional site set in 2944) Hence I’m thinking maybe I just hook in after the fact and re-write the date on the page as Year + 930, but store everything as-is. So in effect in the backend nothing changes, but all dates when displayed are simply rendered as plus 930. Then it becomes a question of (a) finding all the dates to edit and (b) figuring out a little function that simply adds 930 years before the text is outputted to the renderer.
You can do this in your theme pretty easily. Just find out where the date is being output and use something like this:
`<?php
$date_stamp = strtotime ($post->post_date);
$year = date (“Y”) + 930;
$date = date (“j/n/”, $date_stamp).$year;
?>
<p>Entered on <?php echo $date; ?></p>’
You can also easily convert that to a small function that will do the conversion for you and call it when needed.
The only restrictions are that it won’t work properly with leap yers, and that this works with the displayed dates on your posts/pages only. It won’t do anything for the URl’s year/month archive pages thanks to the issues with 2038 that you already know about.
