feat(intl): allow abbreviated months not strictly being title cased (MMM, LLL)

[alestiago]

Describe the bug

The abbreviated month (LLL, MMM) has to be title cased for it to be parsed adequately.

I'm not sure if this is intended, but I think it would improve the overall developer experience if the casing didn't affect the output of the parse.

import 'package:intl/intl.dart' as intl; // ^0.19.0

void main() {
  final formatter = intl.DateFormat.LLL();
  final date1 = formatter.parse('Mar');
  print(date1); // 1970-03-01 00:00:00.000

  final date2 = formatter.parse('mar');
  print(date2); // FormatException: Trying to read LLL from mar at 0
}

[mosuem]

This is another reason why parsing is considered fragile, and will not be a feature of the upcoming package:intl4x.

[alestiago]

@mosuem are there any plans to deprecate the intl package in favour of intl4x in the future? If so is there a road-map to track the progress?

[mosuem]

We will deprecate intl as soon as intl4x is stable on all platforms - and that might take a while.

Good question about the roadmap. I should set up a tracking issue somewhere. The general idea is that we are wrapping a Rust library, so we need the ability to ship native assets, and tree-shake them, as well as include the .postcard data assets. So still some work to do. The story on the web is much cleaner, as we just expose the browsers Intl object, this is largely done.

[alestiago]

Thanks @mosuem for the insights! I'm looking forward to it being stable on all platforms (I'll imagine the community is too).

Out of curiosity, what motivated the development of intl4x over the continuation of intl?

[mosuem]

intl is a pretty old library with a limited set of features. It must be maintained, bugs must be fixed, some of which are hard to fix (e.g., the data is stored in Dart tables, which makes them un-treeshakeable).

With intl4x, we hope to reduce maintenance while getting more features with less data size.