Add a wrapper for `ucal_getHostTimeZone` to `mozilla::intl::TimeZone`. This
function is only used for the "testing" function framework.
Differential Revision: https://phabricator.services.mozilla.com/D126198
Add setters to change ICU's default time zone.
1. `SetDefaultTimeZone()` sets the default time zone from a time zone identifier.
2. `SetDefaultTimeZoneFromHostTimeZone()` synchronizes the default time zone with
the host system's time zone.
The two new methods will be used in the next part to replace ICU calls in
`js::DateTimeInfo::internalResyncICUDefaultTimeZone()`.
Differential Revision: https://phabricator.services.mozilla.com/D126196
ICU doesn't provide a C-API for time zone functions, but instead requires to
use `UCalendar`. This adds a noticeable overhead, because whenever time zone
offsets are computed, it's first necessary to set the time on a `UCalendar`,
which triggers a recomputation of all calendar fields. And because time zone
offset computation is used for JavaScript's `Date`, which is widely used, we
should avoid performance regressions compared to the current code which is
using the ICU C++ API.
We can only safely use the ICU C++ API when we don't use the system ICU,
because C++ doesn't have a stable ABI, so the ICU C++ API code paths are only
taken when `MOZ_SYSTEM_ICU` is `false`.
Differential Revision: https://phabricator.services.mozilla.com/D126192
Add four additional methods to `mozilla::intl::TimeZone`:
1. `GetDSTOffsetMs()` to return the daylight saving offset at a specific UTC time.
2. `GetOffsetMs()` to return the time zone offset at a specific UTC time.
3. `GetUTCOffsetMs()` to return the UTC offset at a specific local time.
4. `GetDisplayName()` to return the display name of a time zone.
All four methods will be used to replace ICU calls in "js/src/vm/DateTime.cpp".
Differential Revision: https://phabricator.services.mozilla.com/D126191
The filter type is `UCAL_ZONE_TYPE_ANY` to ensure all possible time zones are
returned, and not just CLDR canonical time zones. (CLDR canonical time zones
are different from IANA canonical time zones.)
Differential Revision: https://phabricator.services.mozilla.com/D125576
- `TimeZone` objects can be created with any time zone identifier, so the "Default"
part in the name isn't correct.
- The "TimeZone" part is no longer needed, now that there's a distinct class for
`TimeZone` objects.
Therefore let's rename `GetDefaultTimeZoneOffsetMs()` to `GetRawOffsetMs()`.
Differential Revision: https://phabricator.services.mozilla.com/D125575
Time zone functions being part of `UCalendar` is an internal implementation
detail of ICU4C. For the public unified Intl API we should rather follow
Temporal (or ICU4C's C++ API) and have a separate `TimeZone` class.
The files were moved using `hg cp` to preserve the file history.
Differential Revision: https://phabricator.services.mozilla.com/D125574
ICU's public API only provides a function to return the preferred hour cycle
(`udatpg_getDefaultHourCycle()`), whereas for `Intl.Locale` we want to be able
to determine all allowed hour cycles. So we have to do it the hard way and
directly read ICU resource bundles to get the data we need for this feature.
Differential Revision: https://phabricator.services.mozilla.com/D125571
Currently only provides a single method to retrieve all available measurement units.
`MeasureUnit::GetAvailable()` returns an enumeration similar to the other Intl
classes which use `intl::Enumeration`. This approach gives us a more consistent
API, because it abstracts away the internal ICU implementation, which looks up
the measurement units through `UResourceBundle`. But it also means the
implementation is slightly more complicated due to this additional abstraction.
The default constructor was deleted because all methods are static.
Differential Revision: https://phabricator.services.mozilla.com/D125966
Currently only provides a single method to retrieve all ISO currency codes.
The default constructor was deleted because all methods are static.
Depends on D125674
Differential Revision: https://phabricator.services.mozilla.com/D125675
In contrast to the existing `GetBcp47KeywordValuesForLocale()` method, this
method returns all possible collation types, even the ones which aren't supported
by a specific locale.
Depends on D125672
Differential Revision: https://phabricator.services.mozilla.com/D125673
This patch will probably not compile on its own, but requires the SpiderMonkey
side as well. It aims at building a components bag interface that can be
then used in SpiderMonkey to back the ECMA 402 API.
Differential Revision: https://phabricator.services.mozilla.com/D123822
This patch will not compile. It naively copies over the hour cycle code
from SpiderMonkey into the unified components. In a following patch,
these will be modified to use only the unified types.
Differential Revision: https://phabricator.services.mozilla.com/D123821
As discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1719747#c6,
In Part 1, the ownership of the Span in PartsVector is maintained by
ICU. This method adds a callback so js::intl::ListFormat could copy the
content of the Span to Spidermonkey, and mozilla::intl::ListFormat could
use ScopedICUObject to release the string owned by ICU earlier.
Differential Revision: https://phabricator.services.mozilla.com/D123166
This code will be used by RelativeTimeFormat, so we need to move it to a place
where it will be accessible to both NumberFormat and RelativeTimeFormat.
Differential Revision: https://phabricator.services.mozilla.com/D121411
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
These new functions match the similarily named functions on `intl::NumberFormat`.
Also add some assertions to `NumberFormat::formatToParts()` when called with
decimal number strings to ensure non-finite number strings aren't used here,
because we always pass `Nothing()` for the number in this method.
Differential Revision: https://phabricator.services.mozilla.com/D119758
`NumberFormatterSkeleton::toRangeFormatter()` receives the two additional options
as extra parameters, because that's simpler to implement compared to storing the
`NumberRangeFormatOptions` struct in `NumberFormatterSkeleton`. We can revisit
this approach should `NumberRangeFormatOptions` ever get more additional options.
Differential Revision: https://phabricator.services.mozilla.com/D119757
Add `NumberPartSource` to `NumberPart` in preparation for part 18.
Also changes the underlying type of `NumberPartType` to `int16_t` to ensure the
size of `NumberPart` doesn't change on 32-bit platforms when adding
`NumberPartSource`. (Note: `sizeof(NumberPart)` is 16 on 64-platforms with or
without this change.)
Differential Revision: https://phabricator.services.mozilla.com/D119755
In the next part of this patch stack, we want to record the "source" of a
number part. The source is used when formatting number ranges to record if the
formatted number part belongs to the start resp. end of the number range.
Differential Revision: https://phabricator.services.mozilla.com/D119754
Change `GetPartTypeForNumberField` to a free function so a later part in this
patch stack can call it when processing number ranges.
Differential Revision: https://phabricator.services.mozilla.com/D119753
The "Intl.NumberFormat v3 API" proposal adds support to format arbitrarily large
decimal numbers. For example it's now possible to format the decimal number
1e1000 by passing the string `"1e1000"` to the `format` function.
`ToIntlMathematicalValue()` preprocesses the number as follows:
- Non-finite values (NaN and infinities) are always stored as `double` values.
- Positive and negative zero are also stored as `double` values.
- Non-decimal strings like `"0x10"` are stored as BigInts, because ICU only
supports decimal number strings.
- An error is thrown if the exponent is too large to workaround ICU limitations.
Normalising non-finite values and ±0 is done in preparation for part 17.
Differential Revision: https://phabricator.services.mozilla.com/D119752
First set of new options added in the "Intl.NumberFormat v3 API" proposal.
- All ICU rounding modes are added. (The Intl proposal doesn't support "HalfOdd".)
- The rounding mode names match the names in the Intl proposal, which are
different compared to the ICU names.
- Significant digits options are ignored when rounding increment is used. This is
an ICU limitation. The Intl proposal will throw an error if both options are
used at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D119745
Add `intl::NumberRangeFormat` based on the existing `intl::NumberFormat` class
and use it to implement `intl::PluralRules::SelectRange()`.
Most ICU number range formatting functions are still draft APIs and therefore
are guarded by `#ifndef U_HIDE_DRAFT_API`. Instead of requiring `mozilla::intl`
users to also use `U_HIDE_DRAFT_API`, add two additional preprocessor definitions
(`MOZ_INTL_PLURAL_RULES_HAS_SELECT_RANGE` and `MOZ_INTL_HAS_NUMBER_RANGE_FORMAT`).
When `MOZ_INTL_HAS_NUMBER_RANGE_FORMAT` isn't defined, `intl::NumberRangeFormat`
is an empty class. We could also hide the complete class if the preprocessor
guard isn't defined, but the other approach results in fewer `#ifdef` guards.
Differential Revision: https://phabricator.services.mozilla.com/D119742
SpiderMonkey requires the BCP 47 locale extensions, which involves iterating
over the keywords in ICU, and mapping them to the BCP 47 version. Specifically,
this will change the "phonebook" keyword to "phonebk". This should hopefully
expose a simpler API to SpiderMonkey, the only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D120903
This collator attempts to match the options bag from the Intl.Collator API
from ECMA-402. It is built to be compatible and consistent across both Gecko
code and SpiderMonkey code. Its behavior is designed to match ECMA-402.
Differential Revision: https://phabricator.services.mozilla.com/D120494
SpiderMonkey requires the BCP 47 locale extensions, which involves iterating
over the keywords in ICU, and mapping them to the BCP 47 version. Specifically,
this will change the "phonebook" keyword to "phonebk". This should hopefully
expose a simpler API to SpiderMonkey, the only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D120903
This collator attempts to match the options bag from the Intl.Collator API
from ECMA-402. It is built to be compatible and consistent across both Gecko
code and SpiderMonkey code. Its behavior is designed to match ECMA-402.
Differential Revision: https://phabricator.services.mozilla.com/D120494
Modifies TestPluralRules.cpp to assert that all result values are okay
before unwrapping them. Previously the test suite would crash if an
error result was unwrapped. Now it will fail the test and report the
failure.
Differential Revision: https://phabricator.services.mozilla.com/D119465
Change `DateTimePatternGenerator::GetBestPattern()` to call `udatpg_getBestPatternWithOptions()`,
so we can adjust the computed pattern to use 2-digit representation when it was requested by the
user.
Differential Revision: https://phabricator.services.mozilla.com/D118728
This patch adds a DateTimeFormat class for use in the unified
internationalization API. Currently it's only targeting the
ICU code in the Fluent API. The plan is to use it in the Fluent DOM
code, as well as in SpiderMonkey as a centralized API for performing
datetime formatting.
Differential Revision: https://phabricator.services.mozilla.com/D114114
This adds a fallible factory method to create new NumberFormat instances. This
allows us to report initialization errors at time of initialization, rather than
when format is called, and remove internal checks in the implementation for
successful initialization.
The existing fluent code assumes that creating a NumberFormat instance always
succeeds. This patch updates that code to handle failures.
Differential Revision: https://phabricator.services.mozilla.com/D114593
This temporarily adds intl::NumberFormatterSkeleton to the public API so that
we can use it in PluralRules. This allows us to remove the SpiderMonkey
NumberFormatterSkeleton implementation when we convert SpiderMonkey to use
intl::NumberFormat.
We can remove intl::NumberFormatterSkeleton from the public API when we
implement intl::PluralRules in Bug 1704509.
Differential Revision: https://phabricator.services.mozilla.com/D111887
The SpiderMonkey call sites need both the pointer and the length when
copying/deflating the string, so this changes the API to expose the underlying
string_view.
While we're here, this updates the API to use mozilla::Result.
Differential Revision: https://phabricator.services.mozilla.com/D112801
This adds a fallible factory method to create new NumberFormat instances. This
allows us to report initialization errors at time of initialization, rather than
when format is called, and remove internal checks in the implementation for
successful initialization.
The existing fluent code assumes that creating a NumberFormat instance always
succeeds. This patch updates that code to handle failures.
Differential Revision: https://phabricator.services.mozilla.com/D114593
This temporarily adds intl::NumberFormatterSkeleton to the public API so that
we can use it in PluralRules. This allows us to remove the SpiderMonkey
NumberFormatterSkeleton implementation when we convert SpiderMonkey to use
intl::NumberFormat.
We can remove intl::NumberFormatterSkeleton from the public API when we
implement intl::PluralRules in Bug 1704509.
Differential Revision: https://phabricator.services.mozilla.com/D111887
André Bargull
Jonathan Kew
criss
Yoshi Cheng-Hao Huang
Greg Tatum
Greg Tatum
Alexandru Michis
Dan Minor
Andi-Bogdan Postelnicu
Narcis Beleuzu
Erik Nordin
Brindusan Cristian