need "yy-ddd-hh:mm:ss ==> (time_t) clock" converter

[Guy Harris]

In article <TSINGLE.91Jan18120847 at sunland.gsfc.nasa.gov>
  tsingle at sunland.gsfc.nasa.gov (Tim Singletary) writes:
> Help!  I need something to convert yy-ddd-hh:mm:ss (i.e. year,
> day_of_year, hour, minute, second) to a unix-style
> _number_of_seconds_since_00:00:00_GMT,_Jan._1,_1970_.
> 
> I tried to use Sun's timelocal() function but couldn't get it to work (it
> lets you pass both _day_of_year_ and _month,_day_of_month_ with no way
> to specify which is correct!).

It lets you pass day-of-year, but it ignores it.  It looks at month and
day-of-month.  (As one of the Timezone Caballeros, and as the person who
put the "Arthur Olson" timezone stuff, including "timelocal()" - which
was adapted from code by Robert Elz, from an idea by Bob Kridle - into
SunOS 4.x, I know whereof I speak here.)

> Ideally what I'm looking for is source code to a timelocal() function,
> but any tips or suggestions will be appreciated.

Try grabbing the source to the "Arthur Olson" timezone code - the SunOS
code, as indicated, comes from that - from some archive site; it was
posted to "comp.sources.unix" or somesuch at some point.

In article <1991Jan18.200700.11045 at msuinfo.cl.msu.edu>
  jap at convex.cl.msu.edu (Joe Porkka) writes:
>Since your using a Sun you can use strptime(), at least
>in SunOS 4.1.

No, not entirely.  "strptime()" converts a character string into a
"struct tm"; "timelocal()" - and "mktime()", in ANSI C and/or
POSIX-compliant systems such as SunOS 4.1 (POSIX, not ANSI C, in the
case of 4.1) - convert a "struct tm" into a UNIX time.

Think of "strptime()" as being the "inverse" of "strftime()", and
"timelocal()"/"mktime()" as being the "inverse" of "localtime()".

>I have no idea if this is a Sun defined function, or an ANSI
>function.

It's a Sun-defined function, and it doesn't really do what such a
function should do (as the person who defined it, I have the right to
say it's the wrong answer :-)).

It shouldn't be responsible for figuring out which fields of a time/date
specification may be elided, because that means it has to interpret the
format specification in more detail than is appropriate.  Instead, it
should blindly match the string against the format, and some
higher-level routine should try matching various format strings, e.g. 
one with the "seconds" field of a time and then one without. 

Unfortunately, AT&T's S5R4 "getdate()" routine, which operates similarly to
the aforementioned higher-level routine, doesn't seem to be quite right,
either; it's not affected, as far as I know, by the LANG or LC_TIME
environment variables except to the extent that it might change the
names it's willing to accept for months - I don't think you can set LANG
and have it change the syntaxes it's willing to accept for dates, times,
or date+time.