The jiff::tz::TimeZone::system() call is infallible, even though it can of course fail to find a system's configured time zone. If it fails in this regard, it will fall back to UTC. (As libc does, for example, if /etc/localtime doesn't exist on my Linux system.)
But, it would be nice if we had a TimeZone::try_system() that returned an error instead of an automatic fallback to UTC. This came up in GitoxideLabs/gitoxide#1474, where it was suggested that it would be nice to alert the end user of the system time zone couldn't be found.
One complication here is the error message. Currently, a lot of the "details" are written as trace! logs. And smushing all of those details into a single error message is probably the wrong way to go? On the other hand, just returning "couldn't find system configured time zone" is also probably not great either. So some thought should go into what the failure mode actually looks like here.
The
jiff::tz::TimeZone::system()call is infallible, even though it can of course fail to find a system's configured time zone. If it fails in this regard, it will fall back to UTC. (Aslibcdoes, for example, if/etc/localtimedoesn't exist on my Linux system.)But, it would be nice if we had a
TimeZone::try_system()that returned an error instead of an automatic fallback to UTC. This came up in GitoxideLabs/gitoxide#1474, where it was suggested that it would be nice to alert the end user of the system time zone couldn't be found.One complication here is the error message. Currently, a lot of the "details" are written as
trace!logs. And smushing all of those details into a single error message is probably the wrong way to go? On the other hand, just returning "couldn't find system configured time zone" is also probably not great either. So some thought should go into what the failure mode actually looks like here.