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