Allow overload for interpreting two digit years in Date.create

[jason-codaio]

Handling two digit dates is ambiguous. There looks like some current heuristics around how to handle this, but it would be good to allow it to be configurable so applications can decide when they want to flip from being forward looking to be backward looking.

Right now it appears 50 is the inversion point. 50 -> 2050 51 -> 1951

[andrewplummer]

So, any ambiguity in the interpretation of dates (including 2 year dates, units without a specific larger unit set, such as just "Wednesday", etc) are handled with the past and future options. You can find them here.

[jason-codaio]

That is not particularly helpful because they only gives you the options of: A) Always pick the future B) Always pick the past C) Write your own date parser to find the year and set the correct setting at which point you wouldn't bother using sugar-dates.

I would expect some overload similar to moment.parseTwoDigitYear that allows you to set the year based on the two digit date found. I assume this would go into the options similar to the way timezone support is exposed.

[andrewplummer]

Maybe you could tell me what you're trying to do and how you would interpret a 2 digit year?

[jason-codaio]

I'd like to configure sugar to follow Excel conventions where two digit dates 0-30 are in the 2000s and 31-99 are in the 1900s. This would be easily configurable with a twoDigitYear option:

const twoDigitYear = (year) => {
  if (year > 30) {
    return 1900 + year;
  }
  return 2000 + year;
}

[andrewplummer]

OK this seems reasonable. First, since I managed to dig it up, please note that Sugar follows RFC 2882 here:

Where a two or three digit year occurs in a date, the year is to be
interpreted as follows: If a two digit year is encountered whose
value is between 00 and 49, the year is interpreted by adding 2000,
ending up with a value between 2000 and 2049.  If a two digit year is
encountered with a value between 50 and 99, or any three digit year
is encountered, the year is interpreted by adding 1900.

However, you've pointed out that other standards exist, so it seems reasonable to support them. It seems to me that this should support a function as you suggest, whose input is the 2 digit year token (as a string), and whose output is a number (string works too but will be coerced to a number in the end).