red said:
Perhaps, but I don't read comp.lang.c, don't want to spend the time
sifting through any unrelated chaff there, and since the C89 standard is
incorporated (by reference) into the C++ Standard, it would seem to be
relevant and on-topic here.
I'm well aware that gmtime() takes a time_t*. I was wondering what
gmtime is supposed to do if the *value pointed to by its parameter* is
pre-epoch (negative).
Here you go again!.. There is no "epoch". Negative values, except the
single negative value of (-1) can still be valid. Nothing in the Standard
says that 'time_t' is an arithmetic (or integral) type, either. It is
possible that in C++ the type 'time_t' is a user-defined type that simply
has a conversion from, say, 'int', and supplying (-1) creates an object of
type 'time_t' that is somehow "invalid". Since you're not supposed to be
looking at the contents of 'time_t' in a portable program, and only use it
to pass back and forth between time functions, any implementation of that
type is possible.
> I had figured that was implicitly understood.
There is nothing implicit when it comes to Standards. I thought that was
implicitly understood.
> I
had forgotten that -1 is the "invalid time_t" value.
So it's implementation specific (what "negative time" does). That's
what I was looking for. Since I'm looking for portability, I'll check
for negative values pre-call, or 0 returns from gmtime.
You can't portably "check for negative values". It is unspecified that
_any_ negative value of 'time_t' is bad. It specifies that only
(time_t)(-1) is "invalid", meaning that no calendar time is available.
There are two functions in the C Standard Library that return a time_t
value: 'time' and 'mktime'. For all we know they _may_ return something
like (time_t)(-7777) and it should be considered a _valid_ value (in that
particular implementation).
V