8
$\begingroup$

40 years ago I read a book, but couldn't remember the title. I've been looking for it for a while, and I finally (finally!) found it!

And then I worked out why it took so long. It hasn't been released yet! In fact, according to this website I found it on, it won't be released for another seven millenia - when the Earth's spin will be so fast that December will have (at least) 80 days. Global warming? Pah!

Good book! IF you can wait 7,143 years...

http://www.holisticpage.com.au/out-of-this-world-science-fiction-stories-edward-blishen/9780753462461 (Note I’ve told them of this: they may fixhave fixed it.)

Now obviously no human entered this wild date. It's a mis-decode of something - perhaps the ISBN? My question is: can anyone think of an existing decoding algorithm that was so messed up it would invent an entirely new calendar?

Improve this question
$\endgroup$
  • $\begingroup$ Are you sure that's not BC? ;D $\endgroup$ – jpmc26 Jan 8 '19 at 1:02
  • $\begingroup$ @jpmc26 I don't know which is more believable: a book coming back in time, or a printing press invented 10,000 years before Gutenberg $\endgroup$ – John Burger Jan 8 '19 at 1:08
15
$\begingroup$

Not a real answer:

It's not an isolated issue, it seems. There is another one I found here and again the actual date is 16 September 2008
Same is the publishing date of the book in the question. It is worth noting that if we write down the date 16 September 2008 in 'american style' mmddyyyy we get the number 09162008 and this number contains the wrong 'year' 9162.
The likely explanation here is a parse algorithm error (code snippet courtesy of @IanMacDonald): 

 function getDateString(input) {
     let months = ['January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'November', 'December'];
     let match = (input + "00000000").match(/^0*([1-9][0-9][0-9][0-9])([0-9][0-9])([0-9][0-9])/);
     let year = match[1];
     let month = (12+(match[2]-1))%12; // Make sure we're zero-indexing months
     let day = match[3];
     return day + ' ' + months[month] + ' ' + year;
 }

Improve this answer
$\endgroup$
  • 1
    $\begingroup$ Yes, the likeliest answer here is that whoever is parsing the date has made an assumption about component ordering. $\endgroup$ – Ian MacDonald Jan 7 '19 at 14:38
  • 4
    $\begingroup$ I can imagine that the date was 9/16/2008. Strip all non-digits, pad with a zero at the back, because we need 8 digits, then interpret as yyyymmdd. That would mean that December was represeted by 00. I can also imagine that every illegal month is shown as December, if the code goes like this:: ...; if (m==11) return "Nov"; return "Dec"; /* Treat everything else as Dec ;) */ $\endgroup$ – M Oehm Jan 7 '19 at 15:04
  • $\begingroup$ @MOehm Yep, sounds possible but basically it's a algorithm/programmers mistake. $\endgroup$ – rhsquared Jan 7 '19 at 15:10
  • $\begingroup$ Follow-up game: find all entries on the website that have the incorrect date format entered in their database. Bonus points if you use the open API to scrape all their data, then report back to them with a list of date conversions they need to update. $\endgroup$ – Ian MacDonald Jan 7 '19 at 15:30
  • 2
    $\begingroup$ With regards to 00 being December, maybe they just applied a mod 12 to bring every input into the range 1 to 12, i.e. something like month = ((input-1)%12)+1. This makes 01=13=25..=January, and so on until 00=12=24..=December. $\endgroup$ – Jaap Scherphuis Jan 7 '19 at 15:41
3
$\begingroup$

This could be a human error - people are very capable of doing more messed up things than computers! It looks like it was published on the 16/09/2008 or 9/16/2008 in american date format. the year probably comes from 9162 being put into the yyyy section, and the 80 from a corruption of '08, however not sure where December has come into it!

(From a quick google it doesn't look like date is stored in the ISBN number https://www.isbn-international.org/content/what-isbn)

Improve this answer
$\endgroup$
  • $\begingroup$ It could be human error - but this was from a book site, so I assumed it was coming from some database somewhere. Yes there was a 2008 edition (some 10 years after the anthologist’s passing), but it has an ISBN-10 number, which ceased being used after 2006. Also, according to trove.nla.gov.au/work/5510591 there was a 1988 edition - plus I know I read it before then $\endgroup$ – John Burger Jan 7 '19 at 12:54
  • $\begingroup$ Hi, thanks for the extra info! It appears that the older edition (first published in 1988) was titled just "Science Fiction Stories" link and had different ISBN numbers (as appears to be the norm for any variations wiki ISBN ). Which website was it from? Is it a common issue across the site? $\endgroup$ – olim Jan 7 '19 at 13:46
  • 1
    $\begingroup$ That was my thought too. I didn’t investigate too deeply, but I checked other titles - they seemed fine. I’ve edited the question with the URL (apologies for forgetting!) $\endgroup$ – John Burger Jan 7 '19 at 15:34
  • $\begingroup$ December could have come from an "else" condition in the month parsing. if month == 1 then 'January'; else if month == 2 then 'February'; and so on until else if month == 11 then 'November'; else 'December'. Just a guess and there should be better ways of handling that parsing anyway. $\endgroup$ – user33097 Jan 7 '19 at 18:56
0
$\begingroup$

Just to remove the possibility of another answer

the ISBN number was NOT parsed as a UNIX timestamp. Using this, the ISBN number corresponds to a second in the year 2280.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.