[Bug libstdc++/77760] get_time needs to set tm_wday amd tm_yday

["aoliva at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760

--- Comment #5 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
I'm not entirely sure what the point of testing for __clang__ is, really.  Is
libstdc++ used with, or supposed to be used (say, as a system library) with
__clang__?  If so, wouldn't it be useful if it actually worked as expected? 
Currently, the code compiles just fine, though it fails to parse %I%p if
compiled with the actual __clang__ (or when __clang__ is defined on other
compilers for whatever reasons, but that's besides the point).  My thinking is
that either libstdc++ headers are to work with clang, in which case there's an
error in that bit, or they aren't, in which case the preprocessor test is
superfluous and, in this oddball case, harmful.

As for tm bits, my suggestion was to overwrite tm fields internally, not to
expose that externally.  They'd be used as scratch bits.  As in, member
functions in the public interface would not use incoming tm bits as
__time_get_state, but rather a zeroed-out __time_get_state structure, as today,
but when calling the internal implementation primitive do_get, they'd *blindly*
*overwrite* some of the tm bits with those from __time_get_state, and when
do-get returns, they'd pull them back into __time_get_state and out of tm. 
They'd be used as scratch bits, which AFAICT is permissible.  do_get, being
protected and thus more of an internal implementation bit, could make use of
those scratch bits.  do_get overriders could tweak them, for better or worse,
but since this use would be nonstandard, we could probably get away with
assuming any such uses to be libstdc++-specific.  It would probably not be wise
for users to rely on this internal extension, though, since one can hope the
standard will eventually  make room for an implementation of time_get that is
both standard-compliant and compatible with reasonable strptime expectations.