export `TimeZone` to TZif

[scottlamb]

I'd like a method, say jiff::tz::TimeZone::to_tzif, that exports a time zone to TZif, much like jiff::tz::TimeZone::tzif imports a time zone from TZif.

This is by no means urgent as (a) I just heard about jiff and haven't even switched my project to it yet, and (b) I need some Typescript-side functionality to make use of it anyway (likely glue for using MUI's pickers with Temporal + a Temporal TimeZone subclass that imports from user-supplied TZif). But I'm firmly convinced this is useful functionality, and here's why:

My project moonfire-nvr is a server/client deal with a web interface. As it's focused on what's happening physically near the server, it describes time in terms of the server's time zone, regardless of where the user currently is. E.g., if I'm traveling in another time zone, and I'm looking at my home NVR, I still want "midnight" to mean "midnight at home", not "midnight where I am now". Event times are stored in simple machine-centered terms (x fractions of a second since epoch) but the Rust-based server also keeps indices by calendar day (x minutes of total video, x minutes of activity, x discrete events, etc. for this day) so that the client can load immediately with a hint of what happened on those days for general awareness and navigation. The Typescript/React/MUI/...-based client does (and will do) more of the interesting time zone stuff like selecting the start and end of a time range in human-centered terms and rendering a scrub bar with times on it. It's important that the client can translate between machine and human times rapidly (without a round trip) and consistently with the server. I'm currently doing this by communicating the IANA time zone name, but there's no guarantee the server and client actually match in how up-to-date their zone definitions are and such, and the UI experience falls apart when they don't do the calculations in the same way.

Thus I'd like the server to convey the actual TZif-based zone, and the client to load that definition and use it for its calculations.

I expect there are other projects in the same boat where they want a client to be able to accurately perform local operations on a notion of time zone conveyed from the server.

[BurntSushi]

I think this is probably mostly blocked on #20, although perhaps not entirely. #20 technically doesn't need to get TZif data itself to be useful, since it could just represent time zone transitions in memory. But an actual port of zic would enable the use case you describe, in addition to jiff-cli being able to compile its own TZif data without relying on zic. (I don't know if that's a huge benefit or not though.)

I'm still not sold on this however. It seems like there ought to be other ways of achieving your same goal here without needing Jiff to write raw TZif data. For example, why can't you have a check that ensures your tzdb copies are identical on client and server? Or you could make it true by construction by embedding tzdb into both the client and server so that you know all IANA tz identifiers always point to the same binary data.

[scottlamb]

It seems like there ought to be other ways of achieving your same goal here without needing Jiff to write raw TZif data. For example, why can't you have a check that ensures your tzdb copies are identical on client and server? Or you could make it true by construction by embedding tzdb into both the client and server so that you know all IANA tz identifiers always point to the same binary data.

Fair point; a few alternatives:

• "a check that ensures your tzdb copies are identical on client and server". My least favorite option. Currently I'm relying on the zone databases bundled on the respective machines. The server should have a standard tzdb on its filesystem, but the client is a browser which may be Windows-based and anyway doesn't provide general filesystem access. I'm using date-fns-tz for now, which relies on browser APIs to get access to this database, but I don't think there's any existing way to export it in TZif format or the like. I'm not sure how to diff them easily across the network if they don't export to a similar format. And it'd be far preferable—and probably actually easier anyway—to avoid the error by loading the same data rather than just detecting it and complaining which is pretty lame.
• "embedding tzdb into both the client and server". Yes, possible. More likely I'd embed the full database into the server and just transfer the single zone of interest to the client to reduce the transfer size. But I'd prefer to not have to embed the full tzdb into my binary and issue a new release of my software whenever it changes.
• I could also implement detecting the current zone and the tzdb location myself, load the file and send it to both jiff (via TimeZone::tzif) and across the wire. This is doable, but I'd prefer to avoid having my own version of this logic, especially if I expand my platforms beyond "supported on Linux, probably works on other POSIX systems too".

[BurntSushi]

I think we should find a way to do this. But I would like the zic compiler infrastructure to exist first to make this work. Which, I think, will unlock other benefits. Such as making the embedded tzdb for, e.g., Windows, be much smaller.