On Mon, Aug 12, 2019 at 11:08 AM <xxxxxx@ancell-ent.com> wrote:

Agreed on all, the description can say both that these record fields are derived from the pw_gecos struct member, split ... ah ha ha, we need to add for the benefit of implementors the parsing rules and/or genetic Scheme code to parse the raw pw_gecos field.

We don't yet have a stable R7RS-large string SRFI, but the code for string-split can be copied out of SRFI 13 or SRFI 152, so that's not an issue.
 
[ Today I Learned (TIL) favouriteDrink is an ISO standard!  I remain a Padlipsky fan. ]

My favorite Padlipsky RFC: <https://tools.ietf.org/html/rfc962>.  It never got out of experimental status, alas.
 
It'll stay flushed, but it sounds like for the date-time SRFI you'd like SRFI-170 to provide a pointer to the timezone files, which I suppose is practical if you seriously narrow the requirements to a few major Linux distribution families, the BSDs, and ... Apple doesn't like Java at all, what does it do for timezones? 

It seems to vary between releases, but /var/db/zoneinfo and /usr/share/zoneinfo have both been used.  The former is also used by BSD.
 
It's not Python unfriendly, though.  Once given the root, can the date-time SRFI then be expected to open and parse them?

Yes, parsing them is trivial: they are a simple binary format, so you load the whole file as a bytevector and crack it with (rnrs bytevectors) aka (r6rs bytevectors) aka (scheme bytevector).
 
How do we also find out what timezone we're in??

That's precisely what the TZ variable is for.  Technically, it can have one of two formats: IANA TZ format, the familiar continent/city format and its immediate relatives, and Posix TZ format, which specifies the offset from UTC to standard time, the further offset from standard time to daylight time, the abbreviations (in English) for the standard and daylight times, and the parameters of an algorithm for determining the start-of-DST and end-of-DST dates.  Unfortunately, this has to be changed when the standard time offset or DST algorithm changes, and after that all historical date-times are wrong.  I propose ignoring this.

The difficulties arise when there is no TZ variable.  The file /etc/timezone can be any of the timezone name (Linux) , a symlink to the timezone data file (OpenBSD), or (ugh) a *copy* of the timezone data file (FreeBSD).  In the third case the name is irretrievable.  On Cygwin the fallback is to the Windows timezone setting, which maps only imperfectly to IANA time zone names.  On Mac OS you run a program called `systemsetup`, but unfortunately the location of this program changed between releases.

The ironic thing is that Posix tzset() knows the answer already but will not disclose it!  It only sets the timezone, daylight, and tzname files, and throws away everything else.

John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
Long-short-short, long-short-short / Dactyls in dimeter,
Verse form with choriambs / (Masculine rhyme):
One sentence (two stanzas) / Hexasyllabically
Challenges poets who / Don't have the time.     --robison who's at texas dot net