Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Timex to replace Tzdata #31

Open
nallwhy opened this issue Sep 10, 2024 · 6 comments
Open

Support for Timex to replace Tzdata #31

nallwhy opened this issue Sep 10, 2024 · 6 comments

Comments

@nallwhy
Copy link

nallwhy commented Sep 10, 2024

I’m considering replacing tzdata with the tz library, but it’s difficult to make the switch if the tz library doesn’t provide equivalent support for the functions used in timex, which many elixir applications depend on.

Providing support for the key functions that timex uses from tzdata would make the transition much smoother and help more developers adopt tz across a wider range of applications.

function list

  • Tzdata.zone_exists?/1
  • Tzdata.periods_for_time/3
@mathieuprog
Copy link
Owner

mathieuprog commented Sep 10, 2024

I was just thinking about this again this morning. Many developers indeed stick to tzdata while it's slower and still has bugs, and I can only guess the main reason being Timex.

I intend to address this soon enough and allow for a smooth transition from Timex/tzdata to tz.

(Note that I did have a look into Timex a long time ago and found that creating a PR to support any time zone database would be too large of an effort. Therefore I'll come with an alternative solution.)

@mathieuprog
Copy link
Owner

mathieuprog commented Sep 14, 2024

@nallwhy Timex was created before the native calendar API had the full range of functions it offers today.

An idea is to provide a library allowing to migrate to the native apis: https://github.com/mathieuprog/tz_timex
All you would have to do is replace Timex by TzTimex.

It will generate a set of warnings guiding you on how to replace the Timex code.

Could you tell me:

  • is it worth anything for you?
  • if so, can I have the compile errors (there's missing implementations)?

Note that I did not publish on hex right now, you may depend on the github repo.

@nallwhy
Copy link
Author

nallwhy commented Sep 14, 2024

Thanks! I can check it in 3 days as I'm currently on holiday.

@nallwhy
Copy link
Author

nallwhy commented Sep 20, 2024

I understand the concept of TzTimex. The reason we cannot replace Timex right now is due to Timex.parse/2, which is difficult to replace with the native API.

@mathieuprog
Copy link
Owner

https://hex.pm/packages/datix
https://hex.pm/packages/date_time_parser
https://groups.google.com/g/elixir-lang-core/c/5NlpjxGVJIM

Your app or TzTimex could use one of those libraries to provide parse/2. But I'd understand if you don't want to venture into refactoring efforts to replace Timex:)

@nallwhy
Copy link
Author

nallwhy commented Sep 25, 2024

Following TzTimex and your comments, I've succeeded to remove Timex from my project. (I used datix.)
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants