Re: [whatwg] for year input

On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp wrote: > The number of a calendar year really does not fit into to the number > model. Year numbering conveys something different than floating point > numbers or even integers. Standardization of values on ISO years / > proleptic gregorian cal

Re: [whatwg] for year input

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

Re: [whatwg] for year input

Qebui Nehebkau writes: > On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp > wrote: >> The number of a calendar year really does not fit into to the number >> model. Year numbering conveys something different than floating point >> numbers or even integers. Standardization of values on ISO y

Re: [whatwg] for year input

On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp < n...@dieweltistgarnichtso.net> wrote: > Qebui Nehebkau writes: > > > On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp > > wrote: > >> The number of a calendar year really does not fit into to the number > >> model. Year numbering conv

Re: [whatwg] for year input

One useful route may be using ECMAScript's Internationalization API to offload any formatting work. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat seems to imply something like could format according to new Intl.NumberFormat("en-US", { style: "d

Re: [whatwg] for year input

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 plat

Re: [whatwg] for year input

Jukka K. Korpela writes: > 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

Re: [whatwg] for year input

On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp wrote: > I consider year-era-constructs as names for a duration of time. We can > have different names than refer to the same duration of time, like "2014 > CE" and "2557 BE" and "ROC 103". The fact that most of these calendar > systems use a

Re: [whatwg] for year input

Qebui Nehebkau writes: > On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp > wrote: >> I consider year-era-constructs as names for a duration of time. We can >> have different names than refer to the same duration of time, like "2014 >> CE" and "2557 BE" and "ROC 103". The fact that most of

[whatwg] URL spec and IDN

I've noted that the URL specification is currently rather vague when it comes to IDN, and has some uncertain comments about issues related to IDNA2003, IDNA2008, and UTS #46. Roughly speaking, in my experience, there are three kinds of labels: A-labels, U-labels, and "displayable" U-labels. A-

Re: [whatwg] for year input

Hi, The current WebKit/Blink behavior is: - Accept both of the ASCII digits and localized digits - Accept both of the standard decimal point '.' and a localized decimal point - Not accept grouping separators and don't show grouping separators We showed grouping separators in the past. But we

Re: [whatwg] for year input

On Wed, Feb 19, 2014 at 7:51 PM, Nils Dagsson Moskopp wrote: > CE or BE or ROC do not specify units (successor elements), but points of > reference (neutral elements). In my examples, the unit for a time offset > is always the duration of a solar year. Yes, sorry, by 'essentially' I meant that th