edtf.js icon indicating copy to clipboard operation
edtf.js copied to clipboard

Year zero not treated as a leap year

Open SylvainBigonneau opened this issue 5 years ago • 3 comments

Using v2.7.1.

Creating another issue for this, since it happens regardless of the "unspecified" value (currently scratching my head over it by the way):

> edtf('0000-02-29').edtf // expecting '0000-02-29'... wrong
'0000-03-01'
> edtf('0000-02-28').next().edtf // expecting '0000-02-29'... wrong
'0000-03-01'
> edtf('0000-03-01').prev().edtf // expecting '0000-02-29'... wrong
'0000-02-28'

SylvainBigonneau avatar Dec 11 '19 13:12 SylvainBigonneau

I'd have to look this up, but this should be fine, as we're relying on the JavaScript's built-in Date for determining the year, month, day interpretation (we're working strictly with time offsets to make this all easier). I'm not sure exactly what the spec says, but year zero is pre-Gregorian so it will be using the Julian calendar. According to Wikipedia the first leap year in the Julian calendar was 8 AD.

inukshuk avatar Dec 11 '19 15:12 inukshuk

Alright! Yeah I was wondering if it was the right behavior, since I could easily get February 29th with the built-in Date:

> let date = new Date('02/29/0000')
Tue Feb 29 2000 00:00:00 GMT+0100 (Central European Standard Time)
> date.setFullYear(0)
-62162122161000
> date
Tue Feb 29 0000 00:00:00 GMT+0009 (Central European Standard Time)

SylvainBigonneau avatar Dec 11 '19 16:12 SylvainBigonneau

OK so this is probably a 'bug'. If I remember correctly we handle years 0-99 similar to your example: creating the date in the 1900s then computing the offset (taking into account the Gregorian switch I think?). Since 1900 is not a leap year the date is initially set to March 1. The funny thing is that this is maybe more correct than the built-in date (whether Feb 29, 0 AD existed is a philosophical question I'd say)... but we probably get 4 AD 'wrong'.

inukshuk avatar Dec 11 '19 19:12 inukshuk