Yes, that was essentially our original proposal. ISO8601 is a syntax for
proleptic Gregorian dates, so this would be the internal calendar model. ISO
has no such detailed way to specify precision, so this was an add-on we
conceived for Wikidata as an optional annotation to the exact date). The
idea was that all type "date" just means "ISO date + precision" and
that
Julian calendar support is provided by offering transparent conversion
functions to the user (so you could always see and write Julian dates if you
wanted to, without this changing the internal ISO form). The additions of
"before" and "after" came later. The key idea to use ISO format
internally
while still supporting Julian dates with perfect round-tripping is
implemented in Semantic MediaWiki, and the plan was to do this in Wikidata
as well.
That was the theory. In practice, there was the confusion that Lydia
described. Maybe the main problem was that bot authors were writing the
internal data directly (for a while this was almost unfiltered). So when
they would use the API like a user would use the UI ("set 'Julian' if you
want to input your date in Julian"), then it would be wrong, since they
would bypass the Julian conversion that the UI provided. This might have
been the seed for the confusion that arose. This is only of historic
interest now; we don't need to discuss where exactly the errors happened
first. Better focus on fixing the dates now.
Best regards,
Markus
ons. 1. jul. 2015, 18.45 skrev Markus Krötzsch
<markus(a)semantic-mediawiki.org <mailto:markus@semantic-mediawiki.org>>:
On 01.07.2015 18:14, Peter F. Patel-Schneider wrote:
On 07/01/2015 07:00 AM, Pierpaolo Bernardi
wrote:
> On Wed, Jul 1, 2015 at 8:17 AM, Markus Krötzsch
> <markus(a)semantic-mediawiki.org
<mailto:markus@semantic-mediawiki.org>> wrote:
>> Dear Pierpaolo,
>>
>> This thread was only about Julian and Gregorian calendar dates.
If
and
>> how other calendar models should be
supported in some future is
>> another (potentially big) discussion. As you said, there are many
>> issues there. Let's first make sure that we handle the "easy"
99.9% of
>> cases correctly before discussing any
more complicated options.
>
> Lydia Pintscher in the starting email explained that there's a
model
for
> calendars, and unfortunately this model could
be (and has been)
> interpreted in two ways (AFAIU).
>
> My intention was to point out that one of the two
interpretations is not
sound.
This leaves the other one as the only viable one.
Cheers P.
It appears (from the email only---there are no pointers to enduring
documentation on the solution that are attached to the relevant
classes or
poperties) that the chosen method is to store
dates in both the
source
calendar and the proleptic Gegorian calendar
(
https://www.wikidata.org/wiki/Wikidata:Project_chat#calendar_model_screwup).
As you point out, this is not a viable solution
for calendars
whose days do
not start at the same time as days in the
proleptic Gegorian
calendar
(unless, of course, there is time and location
information also
available).
The Wikidata date implementation intentionally restricts to dates that
are compatible with the Gregorian calendar. Although the system refers
to Wikidata item ids of calendar models to denote "Proleptic
Gregorian"
and "Proleptic Julian", the system does not allow users or bots to
enter
arbitrary items as calendar model.
My understanding (and the implementation in WDTK) is that all dates
are
provided in Gregorian calendar with a calendar model that specifies
how
they should be displayed (if possible). The date in the source
calendar
is for convenience and maybe for technical reasons on the side of the
PHP implementation. At no time should the source calendar date be
impossible to convert to Gregorian. We have had extensive discussions
about this point -- Gregorian must remain the main format at all
times.
This does not mean that we cannot have more models in the future.
There
is (currently unused) timezone information, which can be used to store
offsets. Once fully implemented, this might allow exact conversion
from
calendar models that have another start for their days. So maybe this
is
not a case of real incompatibility. However, the timezone support for
current dates needs to be finished before discussing the next steps
into
more exotic calendars.
Best regards,
Markus
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org