1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-06-10 18:10:56 +09:00

LibJS: Always respect user-provided format field lengths

ECMA-402 doesn't explicitly handle a note in the TR-35 spec related to
expanding field lengths based on user-provided options. Instead, it
assumes the "implementation defined" locale data includes the possible
values.

LibUnicode does not generate every possible combination of field lengths
in its implementation of TR-35's "Missing Skeleton Fields", because the
number of generated patterns would grow out of control. Instead, it's
much simpler to handle this difference at runtime.
This commit is contained in:
Timothy Flynn 2021-12-03 08:57:54 -05:00 committed by Andreas Kling
parent 9dc9700e3b
commit e42d954743
Notes: sideshowbarker 2024-07-18 04:46:35 +09:00

View file

@ -647,6 +647,23 @@ Optional<Unicode::CalendarPattern> basic_format_matcher(Unicode::CalendarPattern
}
}
if (!best_format.has_value())
return {};
// Non-standard, if the user provided options that differ from the best format's options, keep
// the user's options. This is expected by TR-35:
//
// It is not necessary to supply dateFormatItems with skeletons for every field length; fields
// in the skeleton and pattern are expected to be expanded in parallel to handle a request.
// https://unicode.org/reports/tr35/tr35-dates.html#Matching_Skeletons
//
// Rather than generating an prohibitively large amount of nearly-duplicate patterns, which only
// differ by field length, we expand the field lengths here.
best_format->for_each_calendar_field_zipped_with(options, [](auto& best_format_field, auto const& option_field) {
if (best_format_field.has_value() && option_field.has_value())
best_format_field = option_field;
});
// 11. Return bestFormat.
return best_format;
}