Closed FObersteiner closed 11 months ago
That is a very nice reference, thank you for linking it.
I'm thinking that keeping zig-tzif would make more sense as part of a datetime library than as a separate component that a datetime library uses.
Especially during testing, the need to manually convert dates into unix timestamps seems less than ideal. I would prefer it if the tests used ISO8601.
I'll probably revive zig-chrono and copy the code from zig-tzif into it. I also wouldn't mind contributing to zdt
. I do want to experiment with zig-chrono's API, because I feel there's a better design out there than the current one.
Yes, that is a good point. A time zone library makes much more sense in combination with a datetime library. That's why I came here in the first place.
As for zdt
, I'm a bit unsure at the moment where this could go. I started it as an exploratory project, but I can see it becoming something useful - if it includes time zone handling. The basics are working at the moment but I have some major changes in mind. I'll keep you posted - your contribution would be very much appreciated :) I also want to have a look at zig-chrono and Rust's chrono. I never got that deep into Rust but let's see.
https://github.com/leroycep/zig-tzif/blob/3cc489a81777dd217cd5bb81629128bbdd6b85a2/tzif.zig#L538
addressing your comment, I think to make this more efficient, we could use days as base period, then add / subtract seconds where needed.
What I'm referring to here is Howard Hinnant's "date" algorithms - C++ library, explanations. For example the calculation of a transition time
t
from a given MonthWeekDay rulemwd
andyear
could look likeunixdaysFromDate
takes a triple year-month-day and returns days since the Unix epoch (Howard just calls it "days_from_civil"). zig-port. I've tested the applicability with an older version of your code, so the field names are different than in the current version etc. but... you get the point ;-)