Exist: [BUG] Leap years in BC era

[enury]

Describe the bug
In eXist 5.2.0, the following date is recognized as valid: xs:date("-0004-02-29"). However, since year 0 does not exist and -0001 (1BC) is directly followed by 0001 (1AD), leap years in the BC era should be off by 1 and therefore odd numbers (-1, -5, -9, -13...).

Expected behavior
xs:date("-0005-02-29") should be a valid date.

To Reproduce

xquery version "3.1";

let $date := xs:date("-0005-02-29")

return $date

[tuurma]

Saxon also complains:

Evaluation will always throw a dynamic error: Invalid date "-0005-02-29" (Non-existent date)

[joewiz]

I can reproduce @tuurma's results in Saxon.

BaseX accepts the date, and seems to account for it here: https://github.com/BaseXdb/basex/blob/3efcf664939e6a48168ad213f1163a538a9d0a89/basex-core/src/main/java/org/basex/query/value/item/ADate.java#L97-L117

It looks like eXist ignores BC entirely: https://github.com/eXist-db/exist/blob/984b64183619b6887a409a0d315e6d262fb31ffe/exist-core/src/main/java/org/exist/xquery/value/AbstractDateTimeValue.java#L746-L771

[dizzzz]

For me, if Saxon has (approx) de same behaviour, there is no bug.

[enury]

If there is no bug, what is the correct behaviour for leap years in BC era?

I can see two options. First :
1BC == -0001 (leap year)
2BC == -0002
3BC == -0003
4BC == -0004
5BC == -0005 (leap year)
But in eXist the 29th february of -0005 is not a correct date, so it does
not take it as a leap year.

The second option is ISO 8601 dates:
1BC == 0000 (leap year)
2BC == -0001
3BC == -0002
4BC == -0003
5BC == -0004 (leap year)
In this case, there is a 29th february of -0004, but any date in the year
0000 is not valid.

Is there a third option that I can't see? If this is not a bug, what am I
missing?

Le mer. 8 juil. 2020 à 21:32, Dannes Wessels [e-mail] a
écrit :

For me, if Saxon has (approx) de same behaviour, there is no bug.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/eXist-db/exist/issues/3477#issuecomment-655712621,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACCBYTKZYXTQSRWBMIQ24CLR2TCUXANCNFSM4OUVZDFA
.

[brihaye]

Please consider this :
https://en.wikipedia.org/wiki/Julian_calendar
This :
https://en.wikipedia.org/wiki/Gregorian_calendar
And this :
https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_calendar

I think that the leap year concept should not be considered before 46 BC and should be location dependant until... 2016 :-)

[duncdrum]

@brihaye not sure how any of this implies that the proleptic Gregorian calendar underlying xs:date should not properly account for leap years when validating @date. Leap year dates occur in sources, even before 0001 and should be castable as date.

[tuurma]

One way to look at it is, that under Gregorian calendar

Every year that is exactly divisible by four is a leap year, except for years that are exactly divisible by 100, but these centurial years are leap years if they are exactly divisible by 400.

Following that, 5 BC is not divisible by 4, thus not a leap year, whatever Julius Cesar or pontifices would have to say about it.

[enury]

Well, I'm looking at wikipedia
https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendarhere, so feel
free to send me more accurate sources :) But this is what I read:

For these calendars one can distinguish two systems of numbering years BC.
Bede https://en.wikipedia.org/wiki/Bede and later historians did not use
the Latin zero, nulla, as a year (see Year zero
https://en.wikipedia.org/wiki/Year_zero), so the year preceding AD 1 is 1
BC. In this system the year 1 BC is a leap year
https://en.wikipedia.org/wiki/Leap_year (likewise in the proleptic Julian
calendar https://en.wikipedia.org/wiki/Proleptic_Julian_calendar).
Mathematically, it is more convenient to include a year 0 and represent
earlier years as negative, for the specific purpose of facilitating the
calculation of the number of years between a negative (BC) year and a
positive (AD) year. This is the convention used in astronomical year
numbering https://en.wikipedia.org/wiki/Astronomical_year_numbering and
in the international standard date system, ISO 8601. In these systems, the
year 0 is a leap year.[4]
https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar#cite_note-4

So these are the two options that I mentioned before: either 1BC, 5BC etc
are leap years, and there is no year 0; or as in the ISO calendar 4BC is a
leap year, and there is also a year 0...

Le jeu. 9 juil. 2020 à 11:12, Magdalena Turska [e-mail] a
écrit :

One way to look at it is, that under Gregorian calendar

Every year that is exactly divisible by four is a leap year, except for
years that are exactly divisible by 100, but these centurial years are leap
years if they are exactly divisible by 400.

Following that, 5 BC is not divisible by 4, thus not a leap year, whatever
Julius Cesar or pontifices would have to say about it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/eXist-db/exist/issues/3477#issuecomment-656010871,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACCBYTJBAIHDQSUEHR6B7WDR2WCWZANCNFSM4OUVZDFA
.

[tuurma]

Relevant spec is here

Part on year zero at least clarifies that 0000 is NOT supposed to be a legal value. Note though that the dateTime section states (emphasis mine)

The date and time datatypes described in this recommendation were inspired by [ISO 8601]. '0001' is the lexical representation of the year 1 of the Common Era (1 CE, sometimes written "AD 1" or "1 AD"). There is no year 0, and '0000' is not a valid lexical representation. '-0001' is the lexical representation of the year 1 Before Common Era (1 BCE, sometimes written "1 BC").
Those using this (1.0) version of this Recommendation to represent negative years should be aware that the interpretation of lexical representations beginning with a '-' is likely to change in subsequent versions.

[ISO 8601] makes no mention of the year 0; in [ISO 8601:1998 Draft Revision] the form '0000' was disallowed and this recommendation disallows it as well. However, [ISO 8601:2000 Second Edition], which became available just as we were completing version 1.0, allows the form '0000', representing the year 1 BCE. A number of external commentators have also suggested that '0000' be allowed, as the lexical representation for 1 BCE, which is the normal usage in astronomical contexts. It is the intention of the XML Schema Working Group to allow '0000' as a lexical representation in the dateTime, date, gYear, and gYearMonth datatypes in a subsequent version of this Recommendation. '0000' will be the lexical representation of 1 BCE (which is a leap year), '-0001' will become the lexical representation of 2 BCE (not 1 BCE as in this (1.0) version), '-0002' of 3 BCE, etc.

But, this spec is from 2004 and here we are 16 years later and '0000' is still not allowed. Bear in mind, this spec doesn't say anything about what is to be considered a leap year.

[duncdrum]

@tuurma so we agree that this is bugged?, since there is no 0000 (which is spec compliant) -0001 is a leap year, so is -0005 ...

PS.: yes I ve been bitten by this bug before

[dizzzz]

Jikes, this is indeed a special case, .....

[dizzzz]

@tuurma there is a newer xsd1.1 spec, chapter 3.3.7.1 Value Space:

Later in D.2.1 the text is repeated.

HTH

[tuurma]

@duncdrum and @enury I agree that one needs to be able to represent dates such as 5BC, Feb 29th and I don't see any other way than writing it as -0005-02-29.

BaseX method of just adding 1 year for negative year values seems to make sense to implement as well.

[tuurma]

@dizzzz thanks, only noticed your comments now. In the light of this spec shall we conclude that

• year 5 BC should be represented as -0004
• a bug to fix is the one which prevents 0000 as allowed value for a year (interpreted as 1BC)?

[duncdrum]

@enury @tuurma we discussed this in the community call and decided that the correct behavior would be to follow the xsd1.1 specs, that is there will be a valid gYear 0000 and leap years occur in e.g. -0004, -0008 etc.

We also noted that some users might not be aware of the spec change and rely on the absence of 0000 so if possible we will make this configurable.

[enury]

Thank you! That sounds good to me.

Le lun. 20 juil. 2020 à 17:42, Duncan Paterson [e-mail] a
écrit :

@enury https://github.com/enury @tuurma https://github.com/tuurma we
discussed this in the community call and decided that the correct behavior
would be to follow the xsd1.1 specs, that is there will be a valid gYear
0000 and leap years occur in e.g. -0004, -0008 etc.

We also noted that some users might not be aware of the spec change and
rely on the absence of 0000 so if possible we will make this configurable.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eXist-db/exist/issues/3477#issuecomment-661118817,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACCBYTJPCTXY4RYTJ5ZLTQTR4RQVZANCNFSM4OUVZDFA
.