Expose or move timezone method from/to date module

[ST-DDT]

Clear and concise description of the problem

The timezone method is more closely related to dates then it is to timezones.

Suggested solution

Move the timezone method to the date module.

Alternative

Expose them from both modules.

Additional context

No response

[Shinigami92]

address will be renamed to location (#1344) 🤔
now the question: is timezone a good fit for location?

[ST-DDT]

Team proposal

• The date/time module will return any timezone.
• The location module will return a timezone matching to the selected locale/country.

[ST-DDT]

Team decision

We will implement that proposal.

[Shinigami92]

In #1678 we deleted all non en timezones and enhanced the en one. In a PR for this issue we then need to extract it out into a global thing and also need to think about how to "filter"? them by selected locale

[matthewmayer]

You could just have a test to check that any locale specific rules are subsets of the global list.

[Shinigami92]

You could just have a test to check that any locale specific rules are subsets of the global list.

I would make it less complex and just merge all specific to one global 🤔
That way no tests are even needed, are they?

[ST-DDT]

and also need to think about how to "filter"? them by selected locale

There is no way to automatically filter them.
The per locale files have to be created by hand (probably once someone actually needs one).

I would make it less complex and just merge all specific to one global 🤔

I'm confused here. What should we do with that global one? IMO comparing the locale specific timezones to the global IANA list at build time is a good and easy to understand solution.

[Shinigami92]

I was not aware that it is fully auto-generated
I just saw the file src/locales/en/location/time_zone.ts that doesn't have a comment that it was auto-generated and also saw no code in our source code to regenerate it and therefore I just thought it can be edited by the next human that comes along

[ST-DDT]

that doesn't have a comment that it was auto-generated

Its written in the PR description.
I dont expect it to change in the future (once it is a global).

[Shinigami92]

Its written in the PR description.

This is lost in the deep void of space to me. The PR is merged and I as a user or contributor don't want to search trough every potential associated issue/PR to understand what was going on in history or which decisions were made for that.

I dont expect it to change in the future (once it is a global).

I agree

[matthewmayer]

tz zones do very occasionally change, perhaps 1 or 2 new zones per year.

For example a new zone America/Ciudad_Juarez was added in November.

https://data.iana.org/time-zones/tzdb/NEWS

But it's slow enough that I think updates can be done manually. And the fact that faker might be missing a few minor zones is not important.

[matthewmayer]

Probably makes sense to add the two lines of code I used to generate as a comment at the top of the file in case someone wants to use this in the future

const {timeZonesNames} = require("@vvo/tzdb")
console.log(JSON.stringify(timeZonesNames, null, 2))