Is it necessary to add more tests given that the filtering methodisValidInAnyCountry has already been tested in the Intl component ?

should we force the new defaults in a deprecated manner?

should we force the new defaults in a deprecated manner?

@ro0NL
We could using an additional option that the developer had to toggle to explicitely specify to disable the deprecation but IMHO, I'm not even sure that most people use obsolete currencies nowadays. This BC will affect 1% or less. The choice is yours...

I don't understand why we need active and active_or_not_at? That's to cover the need of listing only non-active currencies at a given date? Is that a common enough usecase?

I don't understand why we need active and active_or_not_at? That's to cover the need of listing only non-active currencies at a given date? Is that a common enough usecase?

IMHO yes it could be a common use case to list only the non-active currencies for a given date, for the following reasons:

1. For example, if your app needs to search invoices that were issued with the wrong currencies and show a dropdown of those invalid currencies, you would still need two parameters (active = false andactive_or_not_at = the previous year).
2. We have no guarantee that certains symfony applications will be updated within 4 years (the duration of an LTS version). Therefore, the CLDR registry will not necessarily be updated during this period if symfony is not updated. Over this time, currency validity may change, and interfaces (with form usingCurrencyType) may be created to retroactively correct ‘incorrect’ currencies.

WDYT@nicolas-grekas ?

@nicolas-grekas A part from that I think I forgot to process the eventualtz andto-tz attributes from the CLDR. I don't know if it'll change the generated data though but I'll try to fix this point ASAP. seehttps://github.com/unicode-org/cldr/blob/2cac2a547276f5253e0556dc3fb0b8c77e46ab40/common/supplemental/supplementalData.xml#L369-L370

If we want to account for the TZ, maybe we should put timestamps in the metadata instead of date strings? (if that's what we have right now)

If we want to account for the TZ, maybe we should put timestamps in the metadata instead of date strings? (if that's what we have right now)

Yes, or we could convert thefrom andto directly into UTC during the processing to see if theY-m-d date changes. However, we would lose the time at which the change took place... This is a very specific case. Which solution do you prefer?

it might be more readable to have Y-m-d H:i:s UTC strings indeed

it might be more readable to have Y-m-d H:i:s UTC strings indeed

Ok 👍🏻 Do I create another PR for this or can I do the required changes in the current one ?

It should be a separate PR targetting branch 6.4

I will change the format to retrieve time once#61859 is merged. 👍🏻 Done, the tests will pass once#61859 will be merged.

Thank you@Crovitche-1623.