ANSI C. and daylight time

Snoopy seifert at hammer.UUCP
Sat Nov 30 14:26:15 AEST 1985


[ net.internat added to newsgroups list ]

In article <3508 at brl-tgr.ARPA> Makey at logicon.arpa (Jeff Makey) writes:

>The daylight time flag returned by localtime() does NOT have to be
>provided by the operating system.  I looked at the 10-year-old source
>code on my PDP-11/70 PWB UNIX system (no environment variables) and
>observed that localtime() *computes* whether or not the date it is
>processing is between the last Sundays in April and October.

And localtime() still does compute it, in 4.3 BSD and in sysV.2.2.2.2...

> The ONLY input to localtime() (it makes no system calls) is a GMT date/time
>value that is immediately converted to local standard time, then to
>daylight time if appropriate.  There are static variables that are
>hard-coded to indicate: the difference in hours between GMT and local
>standard time;

BINGO!  There's a problem.  These days an awful lot of Unix systems
don't have source code.  Having this stuff hard coded in is no
longer acceptable.  There has to be a way to tell localtime() what
timezone to use, and what flavor of daylight savings time, if any,
to use.  And that way cannot depend on having source code.
Ideally, there would be a system default, set by the system administrator,
and individual users could override this if they wanted.  There's
a couple of ways to go here, environment variables, or a ~/.daterc file.
System V uses $TZ for the timezone and the names of standard and
daylight time.  BSD has $TZNAME for the names.

		Survey time:

--------- cut here and mail to tektronix!tekecs!doghouse.TEK!snoopy ---------

I prefer:
		() a .daterc file
		() environment variables
			() use $TZ for zone and something else for
			   type of daylight time
			() use $TZ for both, assuming that it
			   wouldn't break current sysV
			() other???
		() allow either, with env overriding file
		() other???

Other comments welcome

--------------------  cut here ------- >8 ----------------------------------

> and whether or not conversion to daylight time should
>ever occur (useful throughout most of Indiana, where they are always on
>eastern standard time).

Hmmm, when I was there we used to change from EST to CDT every spring  :-)

One more problem, if Congress (or whoever) goes crazy and keeps changing
daylight time every few years, we may need to allow for a user-supplied
program for calculating whether it's daylight time or not.  (YUCK!)
Ideas?

Snoopy
tektronix!tekecs!doghouse.TEK!snoopy
(tektronix talks to ihnp4, allegra, decvax, ucbvax, ...)



More information about the Comp.lang.c mailing list