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.