[whatwg] Please consider adding a couple more datetime <input> types - type="year" and type="month-day"

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<ryosuke.niwa at gmail.com>  wrote:
>>      
>>> On Mon, Aug 9, 2010 at 8:36 AM, Andy Mabbett<andy at pigsonthewing.org.uk>
>>> 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
>

Received on Thursday, 12 August 2010 07:55:17 UTC