Email list hosting service & mailing list manager

Remaining things to remove mostly per the 80/20 rule hga@xxxxxx (11 Aug 2019 14:35 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (11 Aug 2019 15:10 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (11 Aug 2019 15:15 UTC)
gecos parser implementation Lassi Kortela (11 Aug 2019 17:30 UTC)
Re: gecos parser implementation John Cowan (12 Aug 2019 04:07 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (12 Aug 2019 12:02 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (12 Aug 2019 11:52 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (12 Aug 2019 12:21 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (12 Aug 2019 13:44 UTC)
Timezone files Lassi Kortela (12 Aug 2019 14:00 UTC)
Re: Remaining things to remove mostly per the 80/20 rule hga@xxxxxx (12 Aug 2019 14:07 UTC)
GECOS field parsing Lassi Kortela (17 Aug 2019 08:52 UTC)
Re: GECOS field parsing Lassi Kortela (17 Aug 2019 09:11 UTC)
Re: GECOS field parsing Lassi Kortela (17 Aug 2019 09:16 UTC)
Re: GECOS field parsing Lassi Kortela (17 Aug 2019 09:35 UTC)
Re: GECOS field parsing Lassi Kortela (17 Aug 2019 09:56 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (12 Aug 2019 12:39 UTC)

Re: Remaining things to remove mostly per the 80/20 rule hga@xxxxxx 12 Aug 2019 14:07 UTC

>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