# [RFC] Add IntlDateTimePatternGenerator

- Thread: https://externals.io/message/114124
- Original archive: https://news-web.php.net/php.internals/114124
- Started by Mel Dafert on 2021-04-24T15:12:12+00:00
- Messages: 5
- RFC: Add IntlDatePatternGenerator (Implemented (PHP 8.1)) — https://externals.io/rfc/intldatetimepatterngenerator.md
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #114124 — Mel Dafert — 2021-04-24T15:12:12+00:00

URL: https://externals.io/message/114124#114124

Hi Internals,

I would like to propose an RFC https://wiki.php.net/rfc/intldatetimepatterngenerator to add IntlDateTimePatternGenerator
which exposes ICU's ability to flexibly create localized date/time formatting patterns from a skeleton.

Previous discussion: https://externals.io/message/113831
Implementation: https://github.com/php/php-src/pull/6771

Proposed signature:
```
class IntlDateTimePatternGenerator
{
    public function __construct(?string $locale = null) {}
 
    public static function create(?string $locale = null): ?IntlDateTimePatternGenerator {}
 
    public function getBestPattern(string $skeleton): string|false {}
}
```

There is an open question about what this should be named `IntlDatePatternGenerator` instead, both for brevity and to keep consistency
with `IntlDateFormatter`. (Note that the underlying ICU classes are called `DateTimePatternGenerator` and `DateFormatter`, respectively.)
I am open to switching to the shorter form.

Another open question is the signature, as currently both `__construct` and `create` are exposed (like `IntlDateFormatter`).
Other classes inside the intl extension (like `IntlCalendar`) only provide a static `create` method, and leave the `__construct` method
private. Is there a preferred way, or are both equivalent?

Regards,
Mel

---

## #114130 — Larry Garfield — 2021-04-24T16:54:01+00:00

URL: https://externals.io/message/114124#114130 · In reply to: #114124

> Hi Internals,
> 
> I would like to propose an RFC 
> https://wiki.php.net/rfc/intldatetimepatterngenerator to add 
> IntlDateTimePatternGenerator
> which exposes ICU's ability to flexibly create localized date/time 
> formatting patterns from a skeleton.
> 
> Previous discussion: https://externals.io/message/113831
> Implementation: https://github.com/php/php-src/pull/6771
> 
> Proposed signature:
> ```
> class IntlDateTimePatternGenerator
> {
>     public function __construct(?string $locale = null) {}
>  
>     public static function create(?string $locale = null): 
> ?IntlDateTimePatternGenerator {}
>  
>     public function getBestPattern(string $skeleton): string|false {}
> }
> ```
> 
> There is an open question about what this should be named 
> `IntlDatePatternGenerator` instead, both for brevity and to keep 
> consistency
> with `IntlDateFormatter`. (Note that the underlying ICU classes are 
> called `DateTimePatternGenerator` and `DateFormatter`, respectively.)
> I am open to switching to the shorter form.
> 
> Another open question is the signature, as currently both `__construct` 
> and `create` are exposed (like `IntlDateFormatter`).
> Other classes inside the intl extension (like `IntlCalendar`) only 
> provide a static `create` method, and leave the `__construct` method
> private. Is there a preferred way, or are both equivalent?

For both points, I'd say "consistency wins by default."  So if the other classes in that package already skip "Time" and use ::create() instead of a constructor, you should do the same as well unless there's a very good reason not to.

(Consistency with everything else in PHP that's not that package is a possible reason not to, I grant, hence why it's somewhat subjective.)

--Larry Garfield

---

## #114131 — Mel Dafert — 2021-04-24T17:01:49+00:00

URL: https://externals.io/message/114124#114131 · In reply to: #114130

> For both points, I'd say "consistency wins by default." So if the other classes in that package already skip "Time" and
> use ::create() instead of a constructor, you should do the same as well unless there's a very good reason not to.

The problem with ::create is that in the intl extension itself there are already two different ways used
(`IntlDateFormatter` exposes both, `IntlCalendar::__construct` is private)

---

## #114259 — Mel Dafert — 2021-04-30T16:28:01+00:00

URL: https://externals.io/message/114124#114259 · In reply to: #114130

>For both points, I'd say "consistency wins by default."  So if the other classes in that package already skip "Time" and use ::create() instead of a constructor, you should do the same as well unless there's a very good reason not to.

I have updated the RFC to use switch to the naming without "Time", and added some notes about the naming options.

(On a side note, I realized that HHVM/Hack also implements it without the "Time" part:
https://docs.hhvm.com/hack/reference/class/IntlDatePatternGenerator/ )

I have also removed the open question about the `::create()` method, since the current form is consistent with `IntlDateFormatter`, which is what we want.

---

## #114458 — Mel Dafert — 2021-05-13T08:20:20+00:00

URL: https://externals.io/message/114124#114458 · In reply to: #114259

I am planning to open the vote on this tomorrow, if there aren't any objections.