Since I've been playing around with this a considerable amount now, I might as well go thought the chore of adding more tests, of some more obscure TZ strings. You can sign me up for this :)

IIUC, a UTC offset takes effect at the transition time, not after the transition time. So to get the UTC offset for a given Unix time (s), you are looking for the next transition time less or equal to given Unix time.
In the test quoted above, the UTC offset seems to take effect after the transition time. However, Pacific/Honolulu did not experience LMT anymore at the first transition time, EX:

-2334101315 --> a second before the first transition: LMT
1896-01-13 11:59:59-10:31:26 -37886.0

-2334101314 --> at the transition
1896-01-13 12:01:26-10:30 -37800.0

-1157283000 --> next transition
1933-04-30 03:00:00-09:30 -34200.0
...and so on

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 rule mwdand year could look like

// calculate unix time based on year and m/n/d from rule
// start with year-month, day = 1
t = @as(i64, unixdaysFromDate([3]u16{ year, mwd.m, 1 }));
// now find n'th weekday d
const first_wday = @mod((t + 4), 7);
var days_offset = mwd.d - first_wday; // days to add to reach first specified weekday in month
if (days_offset < 0) days_offset += 7;
var n = mwd.n;
if (mwd.n == 5 and days_offset + 28 >= days_in_month(mwd.m, std.time.epoch.isLeapYear(year))) n = 4;
t += (days_offset + 7 * (n - 1));
t *= std.time.s_per_day;
t += mwd.transition_time;
t -= offset; // correct for UTC offset *before* transition

unixdaysFromDate 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 ;-)

POSIX rules give the standard offset in hours West of Greenwich. However, UTC offsets are "normally" presented in hours(:minutes) East of Greenwich, e.g. as specified by ISO8601, +01:00 means the datetime is 1 hour ahead (in Earth's rotation) of UTC.

Your parser currently returns seconds West, but incorrectly - if I didn't miss something! For example, America/Denver with rule "MST7MDT,M3.2.0,M11.1.0" is 7 hours (25200 s) behind (West of) UTC during standard time but only 6 hours (21600 s) behind UTC during DST since DST is +1 hour East.

I can have a deeper look into this and make a PR if you like.

Hi there @leroycep , I recently found your repo while looking how datetime (and time zone) handling is (or could be) implemented in Zig.

The last update to this repo was quiet some time ago, the language has evolved a bit since then and there's currently a TZif reader in the zig std lib. However, what I found to be missing there is a parser for the POSIX rule, found in the TZif v2+ footer. Since I found this kind of tricky, I was very happy to find your code :)

Do you have any plans with this repo?