Except... why? Wouldn't you like it if your date-based answers to last year's problem were to stay valid? Why don't we change our calendar so that it's never 2015, and we simply continue living in 2014, forever and ever?
Let's define a new date notation, called Eternal 2014 notation, as follows:
- For dates 2014 and before, the dates will be the same as in the proleptic Gregorian calendar.
- For dates in years 2015 and onward, the year will stay 2014, and the month will be the number it would be if the same month cycle in 2014 were to continue forever past month 12. So
2014-85-02. Note that leap days are not accounted for because 2014 is not a leap year.
Your task is to build a program or function that will take a Julian astronomical date as input and return a string with the date corresponding to that Julian date in Eternal 2014 notation, in either
You may assume that the Julian day entered will always be an integer from
1721426 (January 1, 1) to
2914695 (January 23, 3268) inclusive. Years may contain leading zeros to pad to 4 digits or not, but months and days must always have leading zeros to pad to two digits (and years may not contain leading zeros to pad to any number of digits other than 4).
Here are some example inputs and their outputs, in all acceptable formats:
> 1721426 1-01-01 01/01/1 0001-01-01 01/01/0001 > 2086302 999-12-31 31/12/999 0999-12-31 31/12/0999 > 2456659 2014-01-01 01/01/2014 > 2456789 2014-05-11 11/05/2014 > 2457024 2014-13-01 01/13/2014 > 2457389 2014-25-01 01/25/2014 > 2469134 2014-411-07 07/411/2014 > 2567890 2014-3657-29 29/3657/2014 > 2914695 2014-15059-23 23/15059/2014
You may not use any built-in date processing libraries in your language. All calculations must be done algorithmically within the program's source code itself.
The shortest program (in bytes) to achieve this in any language wins.