There also seems to be an issue where a year could be recorded as either
time="+000-00-00T00:00:00Z" or time="+000-01-01T00:00:00Z"
(with precision=9). At least I spotted that my earlier bot runs was doing
this.
These display the same but if you compare the claims they show up as
d
On Thu, Jul 2, 2015 at 4:16 PM, Neil Harris wrote:
> On 01/07/15 15:00, Pierpaolo Bernardi wrote:
>>
> Just for future reference, if anyone's interested, THE book on this topic is
> "Calendrical Calculations".
>
> Alas, their code is closed-source, but the book is still the best reference
> I know
The issues unravel like a ball of string when you look at time.
There is all the cultural stuff, then there is the astronomy, geodesy and
physics that frustrate you if you want to get it right. Leap seconds,
Congress changing daylight savings time, relativity, etc.
The Allen algebra is, I
I thought I lost that discussion? =D
https://www.youtube.com/watch?v=jxhNWYTUiQQ
John
On Thu, Jul 2, 2015 at 11:42 AM, Daniel Kinzler
wrote:
> Am 01.07.2015 um 20:08 schrieb John Erling Blad:
>> Wouldn't it be better to use iso8601 as internal format?
>
> In a relational database schema or a
It is quite common to set Gregorian dates as equal to ISO8601 dates,
and this is correct as long as you only go forward from 1582. If you
want to go backwards you must do so only after negotiation with the
communicating peer, that is "do as we say if you want our data!" When
you hit 1BC the ISO8601
On 01/07/15 15:00, Pierpaolo Bernardi wrote:
On Wed, Jul 1, 2015 at 8:17 AM, Markus Krötzsch
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 yo
On 1 July 2015 at 21:12, Markus Krötzsch wrote:
> ISO has no such detailed way to specify precision,
No, but there is an extension, EDTF, for this:
http://www.loc.gov/standards/datetime/pre-submission.html
with an active, low-traffic mailing list:
http://www.loc.gov/standards/datetime
Am 01.07.2015 um 20:08 schrieb John Erling Blad:
> Wouldn't it be better to use iso8601 as internal format?
In a relational database schema or a triple store, yes. In the primary JSON
blobs, no - there we generally want to store data as entered by the user: if the
user entered a length in feet, we
Thanks. That helps a lot. Is that the way that things are going to be done
in the future, i.e., dates will be stored using the specified calendar model
instead of being converted?
peter
On 07/01/2015 10:52 AM, Denny Vrandečić wrote:
> Peter,
>
> you might be looking for this:
>
> https://www
On 01.07.2015 20:08, John Erling Blad wrote:
Wouldn't it be better to use iso8601 as internal format?
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 preci
That should be "default calendar model".
My screw up... ;/
ons. 1. jul. 2015, 20.08 skrev John Erling Blad :
> Wouldn't it be better to use iso8601 as internal format?
>
> ons. 1. jul. 2015, 18.45 skrev Markus Krötzsch <
> mar...@semantic-mediawiki.org>:
>
>> On 01.07.2015 18:14, Peter F. Patel-S
Wouldn't it be better to use iso8601 as internal format?
ons. 1. jul. 2015, 18.45 skrev Markus Krötzsch <
mar...@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ötzs
Peter,
you might be looking for this:
https://www.mediawiki.org/wiki/Wikibase/DataModel#Dates_and_times
Cheers,
Denny
On Wed, Jul 1, 2015 at 9:48 AM Peter F. Patel-Schneider <
pfpschnei...@gmail.com> wrote:
> Thanks.
>
> This helps in finding out how to reproduce the numbers.
>
> However, I'm
Thanks.
This helps in finding out how to reproduce the numbers.
However, I'm still confused as to how these bits of data are part of the
Wikidata data/knowledge model. Where is the description of
getPreferredCalendarModel, for example?
http://javadox.com/org.wikidata.wdtk/wdtk-datamodel/0.1.0/o
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
wrote:
Dear Pierpaolo,
This thread was only about Julian and Gregorian calendar dates. If and
how other calendar models should be supported in
On 07/01/2015 07:00 AM, Pierpaolo Bernardi wrote:
> On Wed, Jul 1, 2015 at 8:17 AM, Markus Krötzsch
> 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
On 01.07.2015 18:03, Peter F. Patel-Schneider wrote:
...
Even the very nice email from Markus that gives numbers does not provide any
information on where the numbers come from.
I just ran a simple Java program based on Wikidata Toolkit to count the
date values. The features I used for counti
Open a new thread for discussion of calendar models in general.
On Wed, Jul 1, 2015 at 4:49 PM, Markus Krötzsch
wrote:
> On 01.07.2015 16:00, Pierpaolo Bernardi wrote:
>>
>> On Wed, Jul 1, 2015 at 8:17 AM, Markus Krötzsch
>> wrote:
>>>
>>> Dear Pierpaolo,
>>>
>>> This thread was only about Julia
I would find this discussion easier to follow if the Wikidata identifiers
for the various classes and properties were mentioned, and there were
pointers to relevant documentation.
The only Wikidata class or property that I could easily find is Q205892.
It's discussion page, https://www.wikidata.o
On 01.07.2015 16:00, Pierpaolo Bernardi wrote:
On Wed, Jul 1, 2015 at 8:17 AM, Markus Krötzsch
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
On Wed, Jul 1, 2015 at 8:17 AM, Markus Krötzsch
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.
>
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
Please also keep in mind that not all calendars set the start of day
at the same time. This is not a problem if you only have Julian and
Gregorian, but it certainly is if you introduce other calendars.
Two events may happen in the same day in one calendar, and on two
different days in another cal
Hi everyone,
Thanks to Lydia and the team for containing this issue and providing the
necessary documentation for fixing it. For all of you who wonder what
the scale of the issue is (a.k.a. "How bad is it?"), here are some numbers.
The most important years for better understanding:
1582: Gre
It's worrying to hear this.
The Italian Wikisource community strove to get calendar models right.
But I'm sure Magnus will come up with a tool to fix them ;-)
Il 30/06/2015 19:38, Lydia Pintscher ha scritto:
Hi everyone,
I have some bad news. We screwed up. I’m really sorry about this. I’d
rea
I may have said this before; it is very easy to get things screwed up when
a value must reference a datum (a calendar is a datum for time). I think
this is perhaps one of the most common errors on Wikipedia, we just assume
there is a single global datum. Usually it is not, it is only a matter of
pr
Can I just ask all of you who want to demand an enquiry as to how this
happened to hold off until the problem has been fixed
Please
No post mortem while the patient is still alive
Joe
On Tue, 30 Jun 2015 18:39 Lydia Pintscher
wrote:
> Hi everyone,
>
> I have some bad news. We screwed up. I’m
Hi everyone,
I have some bad news. We screwed up. I’m really sorry about this. I’d
really appreciate everyone’s help with fixing it.
TLDR: We have a bad mixup of calendar models for the dates in Wikidata
and we need to fix them.
What happened?
Wikidata dates have a calendar model. This
28 matches
Mail list logo
