`model.datatypes`: how should we handle BCE dates?

[s-heppner]

Currently, _parse_xsd_datetime() and _parse_xsd_date() in basyx/aas/model/datatypes.py detect a leading - on the year and
raise ValueError("Negative Dates are not supported by Python"). This causes the SDK to reject input that is valid per both W3C XSD 1.0
and the AAS JSON/XSD schemas.

The AAS JSON schema pattern for DateTimeUtc (used for BasicEventElement.lastUpdate and EventPayload.timeStamp) starts
with -?, explicitly permitting negative years. The same allowance appears in the AAS XSD schema. W3C XSD 1.0 allows negative years for
xs:dateTime and xs:date more generally (proleptic Gregorian calendar: year 0000 = 1 BCE, year -0001 = 2 BCE, etc.).

Concrete examples from the test data generator that currently fail:

• BasicEventElement.lastUpdate = "-3020-08-21T24:00:00.0Z" (year 3020 BCE, DateTimeUtc)
• Range.min/max = "-0001-02-29T01:02:03" (xs:dateTime, 1 BCE — a leap year in proleptic Gregorian)
• Range.min/max = "-0005-02-29T01:02:03" (xs:dateTime, 5 BCE — also a leap year)

Therefore, we should discuss and answer:

1. Should the SDK support BCE dates at all? AAS use cases centre on industrial asset management; dates before year 1 CE seem
   unlikely in practice. Is this a gap worth closing, or an acceptable known limitation?

2. If yes, what is the right internal representation? Options include:

   • A custom wrapper type that stores the year as an integer field alongside the time components
   • A third-party library such as astropy or isodate
   • A string-passthrough approach (store the raw lexical value, lose the ability to do date arithmetic)

3. If no, should we improve the error? Currently a ValueError is raised, which implies the input is malformed. Something like a NotImplementedError would let callers distinguish "invalid input" from "known SDK limitation." The error message could also be more precise: Python's datetime.MINYEAR = 1 rather than the vague "not supported by Python."