Shane F. Carr

Results 402 issues of Shane F. Carr

`try_from_str` calculates the variant, but it is strict about what fields should be there. `try_loose_from_str` is more lenient, but it doesn't calculate the variant. My input string is `"2000-01-01T00:00Z[Etc/GMT]"` and...

C-datetime
U-temporal

This issue is about how we resolve Unicode extension keywords, such as `-u-hc`, `-u-fw`, `-u-nu`, `-u-co`, and `-u-ca`, i.e. `icu::locale::preferences` enums, against the language, script, and region. ## What we...

question
C-locale
C-meta
A-design

from_epoch_milliseconds_and_utc_offset should be well-defined over all possible i64 millisecond timestamp values. We need to test and fix the conditions near the boundaries.

good first issue
C-time-zone

CLDR offers two variations of the datetime glue pattern, "standard" and "atTime" (and a new one I haven't seen before either, "relative"): ```xml {1}, {0} {1} 'at' {0} {1} 'at'...

help wanted
C-datetime

Currently we have only a `T` field set, which is used for both 12-hour and 24-hour time. This means that day periods are linked even when the application only ever...

C-datetime

Currently we check the checksum only on the first load of a time zone name payload. However, we should retain the checksum in case we need to do further loads,...

T-bug
question
C-datetime

Follow-up to https://github.com/unicode-org/icu4x/pull/6297#discussion_r2000629914 We should figure out a solution for the formatting of generated code files, such as the datetime FFI code files. There are a few general approaches: 1....

T-docs-tests
good first issue
C-process

I put up a design in https://github.com/unicode-org/icu4x/pull/6364, but after discussion, it's not clear that's the design we want. Refer to the PR for additional discussion and guidance.

help wanted
A-ffi
C-datetime

We have some conclusions on https://github.com/tc39/proposal-temporal/issues/2869 and we should add tests for them.

Browsers don't behave consistently. See https://github.com/keymanapp/keyman/issues/13610 A test should be added asserting the behavior of `new Intl.Locale("und")`. Whoever takes this issue should independently verify what the expected behavior should be...