@glyph Everything about datetimes (and probably most human-centric things) is super context-dependent, so what time zone they want to tell the system may have nothing to do with what time zone they want to tell your program.

I don't know what your program is and why you need to serialize civil times with time zones, so it's really hard to have concrete advice here. The only thing I can think of where you'd want it to represent whatever the system local time is, but also pass it around as a civil datetime with an attached zone would be calendar entries, and calendar entries are definitely something you'd want to offer the option to choose a time zone for (since you may say, "Oh this event is two weeks happens at noon in New Jersey, but I live in London").

For pretty much everything else, you either care about the absolute time something happens/ed (e.g. log entries, something that must happen every 24 hours or something), or you care about what time it happens in local time (e.g. "install updates and restart at 2AM because that's when I'm asleep"). In the first case you can basically pass around epoch timestamps or equivalent, and in the second case you can pass around naïve datetimes.

@glyph Though I imagine that a general rule of "try to guess the time zone they care about by looking at `/etc/localtime` or the `TZ` variable or in the Windows registry or whatever" + have an option to manually specify your time zone would basically have you covered. You don't necessarily need a modal at the beginning like, "Hey, what is your time zone, I couldn't possibly figure this out."

@pganssle exactly. The use-case is a library which can be used to create things that are calendar-like, and I want the option for users to provide a useful default.

The real nightmare difficulty question here is “how to I provide a pleasant cross-platform command line experience for *selecting* a time zone without making the user learn about the zoneinfo database themselves”…