You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on my version 2 of intldate. It's a gleam library now inspired from Intl.DateTimeFormat() to format date while respecting human localization. So for my library I did the hard work of figuring out how to exploit the locale data and generate the date but by default gleam_time don't handle IANA timezone.
That's where I found tzifwhich was exactly what I was looking for and everything was perfect for my Erlang support.
Than I tried to run my project with lustre in the browser and that's where something went wrong...
This library is depending on simplifile for loading the tzdata from the OS which is great but that's mean in a browser you don't have access to node:fs. And gleam when you compiled something it will always wrote imports for everything so when the lustre bundle is executed, it will traverse my code, tzif (even if it's never used), simplifile and finally node:fs
I know some ugly technique to solved this issue by making some ugly @external(erlang, ...) to prevent gleam importing my depending code of tzif but that's not the best solution and also this also bite me in my public API where I wanted to provide a intldate.set_time_zone_database(db: database.TzDatabase) for the user to provide an existing TzDatabase globally.
Now in term of solution to this browser incompatibly I can see only one way. Make tzif a sans-io library.
Like you publish on hexpm another library that depend on tzif for providing database.load_from_os() so tzif.
This mean the user can either choose to add this extra dependency for doing the system way or they could use alternate package like zones
But this is a breaking change sadly 😔
Hmm... this is a tough one. Splitting it into a tzif-loader and tzif-parser may be the only real solution for the browser. I was not aware of this issue with lustre.
Reflecting on it, I think making the change to remove the database filesystem loaders from this package makes sense. I think I will do that and do a major version update to 2.0. Then I can make a new tzif-loader package with the helper functions to load the tzif data from the filesystem.
The database.load_from_os and database.load_from_path functions have been moved to a separate tzif_loader package so this one no longer has any io (version 2.0.0 and above).
Activity
devries commentedon Aug 10, 2026
Hmm... this is a tough one. Splitting it into a tzif-loader and tzif-parser may be the only real solution for the browser. I was not aware of this issue with lustre.
devries commentedon Aug 10, 2026
Reflecting on it, I think making the change to remove the database filesystem loaders from this package makes sense. I think I will do that and do a major version update to 2.0. Then I can make a new tzif-loader package with the helper functions to load the tzif data from the filesystem.
devries commentedon Aug 21, 2026
The database.load_from_os and database.load_from_path functions have been moved to a separate tzif_loader package so this one no longer has any io (version 2.0.0 and above).