# Re: [whatwg] for year input

```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.

- R. Niwa

> 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.
>
> Yucca
>
```