# Re: [whatwg] for year input

```Ryosuke Niwa writes [re-ordered]:

> > On Feb 19, 2014, at 7:36 AM, "Jukka K. Korpela" <jkorp...@cs.tut.fi>
> > wrote:
> >
> > 2014-02-19 11:10, Smylers wrote:
> >
> > > Jukka K. Korpela writes:
> > >
> > > > The point is that year numbers aren't really "numbers" in a
> > > > normal sense, any more than car plate numbers, credit card
> > > > numbers, product numbers, or social security numbers are. Surely
> > > > they can be regarded as numbers, but so can car plate numbers
> > > > and the others.
> > >
> > > Except that years do actually form a sequence, and it's possible
> > > to perform maths on them; for instances, subtracting one year from
> > > another yields a duration
> >
> > Mathematically, you are right, but input types aren't based on
> > general properties of quantities but on practical classification of
> > input data. All the examples I gave, including year numbers, are
> > normally input by typing the digits - in contrast with, say, using a
> > color picker, a data picker, or a slider. And year numbers differ,
> > as mentioned, from normal numbers as regards to conventional formats
> > (e.g., 2014 vs. 2,014 or 2'014 or 2 014 or...).
> >
> > So in the input process, a year number is not treated like a number.
> > It typically appears when asking for year of birth or some other
> > event (marriage, employment, etc.). The input check is normally
> > against any non-digit data, the kind of thing we can do with
> > pattern=...
> >
> > Logically, one might say that since asking for a year is very often
> > an alternative to asking for more specific data such as month or
> > day, it should be treated as "date and time input" rather than text
> > input with restrictions. But I don't see how this would be
> > practically relevant. What else could <input type=year> be other
> > than reading some digits? There is the possibility of allowing
> > two-digit numbers, with an implied century, but if that is
> > desirable, authors can use <input type=text pattern=\d{4}|\d{2} and
> > deal with the implied century in their own code.
>
> Let me point out that not every calendar uses simple 2-4 digit numbers
> to denote years.
>
> The Japanese era name calendar system, for example, requires an era
> name such as Showa and Heisei associated with each year.
>
> For example, I was born in Gregorian year 1986 but any Japanese
> government document would say I was born in Showa 61.  My brother was
> born in 1989 but, again, he must write "Heisei 1" instead on any
> government form.
>
> There are also even quite few banks and other organizations in Japan
> that use the era name system for various forms and documents.```
```
Yes, so for a Japanese organization using the era system,
<input type=number> would clearly be inappropriate for years.

An international website wanting a could use <input type=text> and let
users specify the year any way they want — Japanese eras, 2-digit years,
Roman numerals, whatever. This could only realistically be stored as a
string, and the only thing the website could do with it is display it
again; it would be hard to sort by it, or perform restrictions based on
the year, for instance. In this scenario, there's nothing special about
the year so far as HTML is concerned.

Or it could force all users to use Gregorian years, and anybody using a
different system needs to convert their year themselves. At which point
<input type=number> works just fine.

Or the website could internally store all years using one particular
system (say the Gregorian one), but allow input in other systems. This
could be with a free-form text box with interpretation, validation, and
error-handling on the server side, but that would be a substandard user
interface. Better would be to use browser-side JavaScript either to
perform the validation or to provide a year picker which only allows
selecting valid years; regardless of the interface on this picker — for
instance, listing Japanese emperors — it could set the value submitted
with the form to be the equivalent Gregorian year.

Are there many websites currently catering Japanese years by offering
such an interface? If so, it would make sense to create
<input type=year> such that browsers can offer this consistently,
freeing authors from having to develop these for each site.

However, that still wouldn't solve the problem of <input type=number>
putting commas in 4-digit page numbers.

Cheers

Smylers
--