Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T99674#1648463, @daniel wrote, in part:
>
> When referring to "ISO", please note that ISO 8601 actually *changed* from
> representing 44BC as -44 to now using -43 to represent that year. And then,
> later, XSD followed that
daniel added a comment.
This ticket is about whether to write 44BC as -44 or -43. Time zones are
completely irrelevant for this.
When referring to "ISO", please note that ISO 8601 actually *changed* from
representing 44BC as -44 to now using -43 to represent that year. And then,
later, XSD
Smalyshev added a comment.
But the 24 hour span in local time must be converted to Universal Time to
avoid a loss of accuracy; otherwise 24 hour uncertainty becomes approximately
48 hour uncertainty.
Only if you insist on ascribing timezones to dates and comparing dates in
different
Smalyshev added a comment.
Before the implementation of time zones, this is the longitude of the place
of the event, expressed in the range −180° to 180° (positive is east of
Greenwich), multiplied by 4 to convert to minutes.
I think representing two semantics in one value is not a good
Rical added a comment.
To distinguish time-zones we can keep the character T, and for geographic
position, replace T by G.
Our numeration is based on positions of digits, with significant zéros on the
right for empty powers of ten. We cannot truncate the zeros after the left
significant part.
Smalyshev added a comment.
If we require that times contain all the possible digits, up to and including
seconds, then we have to adopt some convention about what to put if the time
is not known to the second
Of course. The natural choice would be to put 0 for time, and 1 for month/day.
Smalyshev added a comment.
The existing entries contain a great many examples of invalid characters such
as 00 for the month or date.
These need to be fixed. It is an easily automatable task.
the date and time of Abraham Lincoln's birth is +1809-02-12T05:42:57 plus or
minus one second.
Rical added a comment.
To convert geographic position to a time more accurate than a day we must
conform to the rules of each country.
Rare are the countries which use solar time as local time. Now mainly Pacific
Ocean islands near the line of date change for touristic reasons. There is no
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T99674#1311475, @Rical wrote:
To convert geographic position to a time more accurate than a day we must
conform to the rules of each country.
Rare are the countries which use solar time as local time. Now mainly
Pacific Ocean
Jc3s5h added a comment.
In reply to Rical' comment of Sun, May 24, 08:41 the current documentation is
at https://www.mediawiki.org/wiki/Wikibase/DataModel and
https://www.mediawiki.org/wiki/Wikibase/DataModel/JSON
I understand that the before and after fields were intended, when a date is
Jc3s5h added a comment.
To get things moving, I'll make a proposal.
1. The following fields from the internal representation (as shown in JSON) are
essential to correctly interpret a time datatype: time, timezone,
precision, and calendarmodel
2. The first change to the meaning of the existing
Rical added a comment.
In the Module:Author, I have chose to compute the negative centuries and the
life times(around year 0) in ISO style and to display them in traditional
years and roman centuries. Then centuries and their limits are also impacted by
this choose.
Linked or out of scope
12 matches
Mail list logo
