There exist well tested and respected algorithms to reliably and easily
convert Gregorian calendar dates (and times of day) to a variety of
forms, including Julian Day Numbers (a real (versus integer) count of
the days and fractions of days from some epoch).
Such conversions are not a readily available for other calendric
systems, even for the precursor to the Gregorian calendar, the Julian
calendar (no relation to the aforementioned Julian Day Number).
While some of the other systems have benefits, many have serious
deficiencies whose corrections could lead to out and out warfare (yes,
violence). Rather than add to the complexity of implementations, it
would be wise to ensure the reliability and extent of Gregorian
implementations ... for example, making available in Javascript
constants for a particular implementation's maximum and minimum and
ensuring that all implementations support, at least, 0001-01-01
00:00:00.000 through, say, 9999-12-31 23:59:59.999 (apologies to
ISO-8601 and the ,/. crowd).
Best!
===
On 2010-08-09 21:47, Kit Grose wrote:
On 10/08/2010, at 10:44 AM, Tab Atkins Jr. wrote:
On Mon, Aug 9, 2010 at 5:41 PM, Ryosuke Niwa<[email protected]> wrote:
On Mon, Aug 9, 2010 at 8:36 AM, Andy Mabbett<[email protected]>
wrote:
On Mon, August 9, 2010 15:10, Daniel Glazman wrote:
Le 09/08/10 03:11, Kit Grose a écrit :
should the "year" field also permit the entry of BC/AD?
Or a jewish year? Or a muslim year? Or counting since the
first tooth of Carolus Magnus or the last onomatopoeia
pronounced by Hannibal during his crossing of the Alps?
All popular calendar systems should be supported. What is the reason we
restrict ourselves to Gregorian calendar?
The Gregorian calendar is the de facto official calendar of the world.
Mixing in other calendars is a horrendous nightmare with nearly zero
benefit.
~TJ
All the more reason for simply letting page authors define any fields they need using the
existing input primitives like "number". I think putting the onus for this sort
of investigation on the UA will simply mean this won't get implemented.
Is any of this discussion being had for the existing date type? The existing spec simply
says a year must be "Four or more digits, representing year, where year> 0".
I think all of this is important discussion not explicitly related to the need for a new input of type
"year". The question we need to identify is whether there's additional value (semantic or
otherwise) in defining input type="year" distinctly from a textual/numeric input with
name="year". The precise behaviour of any such field is surely dependent on an agreement that its
existence is valuable.
—Kit
