Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T85296#1531136, @thiemowmde wrote in part:
>
> > we do know which Gregorian and Julian dates exist.
>
>
> I think we do not (https://en.wikipedia.org/wiki/February_30), but even if we
> do, how does this change anything? Why s
Smalyshev added a comment.
@daniel for "some" calendar models, sure. But for Gregorian and Julian, we know
which dates are good and which are bad. So if you say "Gregorian date on
February 32" it is meaningless since there's no Gregorian date of February 32.
It's not a date in any meaningful se
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T85296#1526755, @daniel wrote in part:
>
> That is exactly what Wikidata's TimeValues are. No more and no less.
True. But the user interface only supports Julian or Gregorian; I don't know if
the API would prevent the addition of
daniel added a comment.
@Smalyshev We can decide to me more or less strict for calendar models we know
well, but there will //always// be the possibility of "bad" dates, since for
some calendar models, we don't even know how to validate. They may not even be
strictly defined. So, conceptually,
daniel added a comment.
@Jc3s5h wrote:
//"Perhaps there could be a concept of a quoted date, with an ability to state
the date, the source, and an entitiy or character string to give the
calendar."//
That is exactly what Wikidata's date are. No more and no less.
TASK DETAIL
https://phabrica
thiemowmde added a comment.
I find it exhausting to explain the same things again and again, to the same
people.
We never said "Wikidata is a repository of data that make sense". You can store
"foo" as an IMDb identifier. You can store "1 January 3100" as a date of birth.
You can store "cucumb
Smalyshev added a comment.
I think obviously wrong dates should not be allowed, even if a source says so,
unless we get a special calendar model for that. Because claiming that somebody
was born on 32th of July is meaningless. Wikidata was supposed to be *data*
repository, and "32th July in Gre
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T85296#1524522, @daniel wrote in part:
> @Jc3s5h: You mean, we could have a calendar model for "Broken Gregorian"? I
> like that idea!
My concern with a "Broken Gregorian" calendar model is the well-demonstrated
willingness of edito
daniel added a comment.
@Jc3s5h: You mean, we could have a calendar model for "Broken Gregorian"? I
like that idea!
It seems clear to me that we shouldn't just allow any input for
Gregorian/Julian dates: the "123rd of Juli" or the "15th of Kittens" should not
be accepted. However, I don't thin
Jc3s5h added a comment.
In reply to daniel's comment at Aug. 1-, 16:14, it seems to me it would be more
common to find, in a source, a date given in an ancient calendar that can't be
precisely converted to Gregorian, than it would be to find a date that purports
to be Julian or Gregorian but is
daniel added a comment.
> It seems to me the purpose of a database is to store the best available
> conclusion, in a calendar that is, or can be converted to, the Gregorian
> calendar. Discussion of the merits of various pieces of evidence is fine for
> history journals, or even a Wikipedia art
Jc3s5h added a comment.
I would agree with @thiemowmde if there were a plausible alternative to the
Gregorian and Julian calendars which might require support in the future. But I
believe that any such alternative would be so drastically different that there
would be no temptation to apply the
thiemowmde added a comment.
All patches listed above are unrelated to this issue. To be more precise, they
belong to the closely related issue of PHP's parser magically "correcting" 31
September to 1 October. I listed the patches as an answer for @Jc3s5h.
This issue needs discussion: Do we want
Lydia_Pintscher added a subscriber: Lydia_Pintscher.
Lydia_Pintscher added a comment.
What's left?
TASK DETAIL
https://phabricator.wikimedia.org/T85296
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Lydia_Pintscher
Cc: Lydia_Pintscher, Jc3s5h, Liux
Addshore added a comment.
All patches in the above comment are now merged
TASK DETAIL
https://phabricator.wikimedia.org/T85296
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Addshore
Cc: Jc3s5h, Liuxinyu970226, Ricordisamoa, Addshore, thiemowmde, J
Jc3s5h added a comment.
I tested JavaScript:
document.write(new Date( 1900, 1, 29 ).toDateString())
Which gave as a result
Thu Mar 01 1900
So this indicates that the JavaScript Date object is the wrong tool for the job
we are doing. I haven't tested PHP, but that is suspect too. So the code t
Smalyshev added a comment.
Even if we allow any string as date, we still have to decide what to do with
such data on export. Most external tools can not work with or even represent
invalid dates. Also, searching, etc. needs some sanity in dates to be able to
compare it. If we allow dates like S
Ricordisamoa added a comment.
In https://phabricator.wikimedia.org/T85296#1125595, @Jc3s5h wrote:
> I find it alarming that 31 September was corrected to 1 October.
That's how JavaScript and PHP work:
> new Date( 2015, 8, 30 ).toDateString()
'Wed Sep 30 2015'
> new Date( 2015, 8, 31 ).to
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T85296#973355, @Addshore wrote:
> Okay, so when entering "31 September 1949" through the Frontend in an edit
> and saved it is formatted as "1 October 1949" and correctly saved as
> "+019-10-01T00:00:00Z"
> This suggests that
thiemowmde added a comment.
I suggest to not implement code that checks for the described type of validity
in the Wikibase' extension. This is something external tools (bots and such)
should do.
Reasoning:
- Something like a "31 February" may exist in other calendar models.
- Different calenda
20 matches
Mail list logo
