Re: 1.6.8 release candidate 0 available for testing.

[Greg Troxel]

Kevin Ryde <address@hidden> writes:

> Greg Troxel <address@hidden> writes:
>
> The bit about %Z is
> 
>          %Z  is   replaced  by  the  locale's  time  zone  name  or
>              abbreviation, or by no characters if no time  zone  is
>              determinable.  [tm_isdst]
> 
> which I suppose is because struct tm is speced without tm_zone.

Probably.  NetBSD libc uses the environment variable or /etc/localtime.

> You'd think a system with tm_zone should use it, but yes no sense
> demanding what doesn't work.

Yes, but the point (from the PR) is that a conforming program doesn't
have to set it, so libc reading it causes undefined behavior, and thus
libc can't read it.

> > Perhaps libguile/strftime.c needs to not assume that strftime(3)
> > will examine fields not specified by the standard, or perhaps that
> > Scheme strftime should define what it does more precisely.  A
> > problem here is that guile uses a structure which is bigger than
> > C89 says.
> 
> Since we initialize tm_zone if it exists we should be safe, but a note
> in the docs about what guile tm:zone might or might not do could be in
> order.

Sure, guile sets it.  Options I see are

1) declare the Scheme proc strftime has extended semantics beyond C99,
   document them, and make the implementation set TZ before calling
   strftime (perhaps unless an implementation which guarantees to read
   tm_zone is detected).

2) Document that the scheme proc strftime conforms, after langauge
   mapping, to C99, and point out that thus tm_zone is expected to be
   ignored because it isn't part of the standard.  Perhaps don't set
   the non-C99 fields in what is used for the libc call to avoid
   nonportable expectations.

The meta-issue I see here is about guile providing consistent behavior
on all platforms.  On some points it seems to do this, but it also at
times just wraps OS libraries.  One of the wins of guile is
portability, and I'd like to keep as much of that as possible.

-- 
        Greg Troxel <address@hidden>