[uClibc]strptime and mktime problem

[Andrew May]

On Wed, Jun 18, 2003 at 07:28:39AM -0600, Manuel Novoa III wrote:
> On Tue, Jun 17, 2003 at 10:50:44PM -0700, Andrew May wrote:
> > On Tue, Jun 17, 2003 at 10:00:18PM -0600, Manuel Novoa III wrote:
> > > On Tue, Jun 17, 2003 at 07:05:44PM -0700, Andrew May wrote:
> > > > The first problem is that strptime() seems to screw up the values of
> > > > everthing in the tm struct.
> > > 
> > > Well, as far as strptime() is concerned, your code above isn't portable.
> > > Quoting from the SUSv3 application usage notes regarding strptime():
> > > 
> > >   http://www.opengroup.org/onlinepubs/007904975/functions/strptime.html
> > > 
> > >   It is unspecified whether multiple calls to strptime() using the same
> > >   tm structure will update the current contents of the structure or
> > >   overwrite all contents of the structure.
> > 
> > The note is regarding "multiple calls to strptime". Now the test code
> > does use the same struct in multiple calls, but I would argue that the
> > first call has values in the structure overwritten that I did not want
> > overwritten. So switch the lines strptime call and setting tm_mday to
> > make it clearer.
> 
> You're picking nits.  The intent of the note is that, as far as SUSv3
> is concerned, there are _no_ guarantees with respect to any fields not
> explicitly set via the format statement.  The application notes go on
> to say:

Interpeting documents is all about picking nits. It would be nice if that
is what they intented, then they should have written it like that.

> 
>   Portable applications should make a single call to strptime() with a
>   format and all data needed to completely specify the date and time
>   being converted. 
> 
> I consciously decided to "trash" all unset fields in order to help detect
> non-portable code.

I can deal with that but it would be nice to be like libc. For now I just
decided to expand the string to have a day of 1 and time of 0.