USL C++ Time class and hpux tztab conversion

Thread View: comp.sys.hp.hpux

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Marcel Bucher Mon, 02 Oct 1995 15:23

#15

Author: Marcel Bucher
Date: Mon, 02 Oct 1995 15:23

56 lines
2669 bytes

Hi out there!

I've run against some problems using the USL Time class.

Here in Central Europe we just switched back from daylight savings
to normal time, but my applications using the Time class still report
daylight saving time.
I've tracked down the problem to this:

Time looks at the environment variable TZ and expects something of the
form: 

       TZ="MET-1METDST;64/5:00,290/3:00"
             ^      ^    ^        ^
             |      |    |        |___ day/hour to switch to winter time
             |      |    |____________ day/hour to switch to summer time
             |      |_________________ name of normal time with GMT offset
             |________________________ name of summer time with GMT offset


whereas the ctime library used by all unix commands on hpux 9.0x (eg date,
ls...)  uses the TZ variable as an index into the hpux file /usr/lib/tztab
with entrys like this:

    # Middle European Time, Middle European Time Daylight Savings Time
    MET-1METDST
    0 3 25-31 3  1983-2038 0   METDST-2
    0 2 24-30 9  1983-2038 0   MET-1
     ^      ^ ^        ^   ^    ^
     |      | |        |   |    |____ name of time and offset to GMT
     |      | |        |   |_________ day of week of switching
     |      | |        |_____________ range of years where the to apply
     |      | |______________________ month of switching
     |      |________________________ range of day of month to switch
     |_______________________________ min/hour of switching


where TZ="MET-1METDST"

The hpux way is much more flexible about the switching day (it gets
computed considering day of week in a certain period), but it seems to be
non standard.

Does anyone out there have any experience with that? How could I possibly
merge the two ways into a single TZ-variable or make the USL library more
hp aware?

Thanks in advance for any help!

--
#include <stddisclaimer.tm>
 ________________________________________________________________________
|                    bucher@euu.siemens-albis.ch                         |
| or X400: c=CH a=ARCOM p=SCN o=SIEMENS-ALBIS ou1=ZRH1 s=BUCHER g=MARCEL |
|________________________________________________________________________|

Re: USL C++ Time class and hpux tztab conversion

#16

Author: Andy J Robb
Date: Thu, 05 Oct 1995 05:38

29 lines
1635 bytes

bucher@zhea008 (Marcel Bucher) wrote:
>The hpux way is much more flexible about the switching day (it gets
>computed considering day of week in a certain period), but it seems to be
>non standard.

In my limited experience, the HP-UX database method is the only one to
allow correct viewing of file timestamps etc. from other years, summer
or winter.  I am not even sure that HP have implemented it in that way
though.  Most 'nix systems just set a global current offset for
localtime vs. UTC.  This gets lumped onto ANY time regardless of
whether it was summer or winter.

Please, please, can we get this FIXED for ALL systems.  IMHO, any
routine that cannot perform the same translation on a time from one
day to the next, is broken.

Regards,
Andy Robb.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2i

mQCNAy/MpRwAAAEEAOt6uBYqT8yv9EmqNhK8m6v+bYi8QjnGW3Bo6iU1gsMj5pa6
MHgq99c8deADbE3cbJ6uZS9v5pZE3WCf6HCQjlB5iULA5RZzMdAumd/WUzuL9UT3
B44D9EqqFIL79FlYb56v4oKFqFp1/J2bIpYUwnUvabGzGjdLrpPl4P16x9sNAAUR
tCNBbmR5IEogUm9iYiA8QUpSb2JiQHBhdmlsaW9uLmNvLnVrPrQhQW5keSBSb2Ji
IDxBSlJvYmJAcGF2aWxpb24uY28udWs+
=/wVD
-----END PGP PUBLIC KEY BLOCK-----

Re: USL C++ Time class and hpux tztab conversion

#17

Author: Frank Slootweg
Date: Tue, 10 Oct 1995 14:00

11 lines
1030 bytes

Marcel Bucher (bucher@zhea008) wrote:
[deleted]
> The hpux way is much more flexible about the switching day (it gets
> computed considering day of week in a certain period), but it seems to be
> non standard.

  What do you mean by "non standard"? ctime(3C) confirms to all the
applicable standards, see the STANDARDS CONFORMANCE part of ctime(3C).
The internal *implementation*, i.e. /usr/lib/tztab, might be non
standard(ized), but, as far as I know, the *syntax and semantics* of
ctime(3C), TZ et al are standard conformant.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads