>From: Lassi Kortela <xxxxxx@lassi.io>
>Date: Monday, August 12, 2019 8:45 AM

> [ pw_gcos stuff, and while it's not "POSIX", since there are well
>   established conventions for interpreting the field, I say we digest
>   it for the user.  Give me a rough spec and I'll add it to the SRFI
>   and Chibi Scheme implementation. ]

>> On the root of zoneinfo:  I think we should expect the implementer
>> of SRFI 170 to figure out where it is, though we could say it's in
>> /usr/share/zoneinfo with these known exceptions, and may be
>> elsewhere.

> One possibility is to readlink("/etc/localtime") and split the
> result at the last occurrence of "zoneinfo", trusting that the
> timezones are under some "zoneinfo" directory on all
> systems. However, knowing the mindset of Unix distributors at large,
> we are unlikely to have such luck. They can't even agree on whether
> development packages should be called "-dev" or "-devel", let alone
> anything more complex. At this rate, it would be simpler to
> hard-code a list of all known top-level timezones and trust that
> those don't change!

Echoing Lassi above, I'm going to strongly argue this is
*fantastically* beyond the remit of a SRFI-170 implementor.  If the
date-time SRFI requires this level of detail, I'd say it's up to the
implementor of it to for example use tools like those we supply in
SRFI-170, to know all the details of "enough" Linux distributions,
plus the few BSD including MacOS ones, and Windows.

Maybe step back from this?  I note the following in POSIX time.h
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html

The <time.h> header shall declare the following as variables:

> extern int    daylight;
> extern long   timezone;

> extern char  *tzname[];

Is the timezone long enough for this SRFI?

- Harold