FW: Installation of tzcode1999e_tar.gz and tzdata1999e_tar.gz

[Guy Harris]

> cc: "localtime.c", line 1260: warning 527: Integral value implicitly converted
> to pointer in assignment.

The problem here is probably that the time zone code depends on the
native OS's header files to declare the "standard" functions, such as
"localtime()" - and "localtime_r()".

The "/usr/include/time.h" on an HP-UX 11.0 system here is defined if the
right collection of 50,000 #defines are pre-defined; it appears that:

	_INCLUDE__STDC__

	_PROTOTYPES

	_REENTRANT

must all be defined.  I'm not sufficiently familiar with HP-UX to know
what we should be doing to define them.

> /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (date.o) was
> detected. The linked output may not run on a PA 1.x system.

Was this compiled on a 32-bit (PA-RISC 1.x) or 64-bit (PA-RISC 2.0)
system?

> But up to here, everything is OK (every executable is in the right place,
> under the /usr/local/ directory, and the PATH variable is set correctly).
> I set the TZ variable to, for example, America/New_York and the date
> command doesn't give me the right time.

What does it give *instead* of the right time?

Are the data files installed in "/etc/zoneinfo" (or whatever directory
was chosen as "TZDIR")?

> I have checked the file /usr/bin/locale and it's a  PA-RISC1.1 shared
> executable dynamically linked. Maybe that's the problem.

In what way is "/usr/bin/locale" involved here?  If it's not involved,
it's probably not the problem.

> Nevertheless, the directory /usr/lib/locale and its subdirectories don't
> exist.

That should affect only the "strftime()" that comes with the time zone
package, which means it might affect the format of the "date" command's
output *IF* it's given a date format argument, but it shouldn't affect
the actual time.