comments of proposals
seismo!nbires!vianet!devine
seismo!nbires!vianet!devine
Thu Dec 11 07:49:54 UTC 1986
Excuse the delay in responding to some of the issues, things
have been rather hectic. Some mail may have been dropped locally
(sorry if I'm talking about something that is solved).
1. Ctime functions. I favor the following small collection:
char* ctime(time_t)
struct tm* localtime(time_t)
struct tm* gmtime(time_t)
char* asctime(struct tm*)
time_t mktime(struct tm*)
int settz(char*) /* set up a user selectable timezone */
int strftime(char*, int, char*, struct tm*)
These supply the time conversion capabilities needed. This set can
be extended with internationalization functions that parallel ctime()
and asctime().
"Maybe" category:
int strfastime(char*, int, char*, struct tm*)
int systz() -- 1) set up the system default timezone
-- 2) not needed if a certain string passed
-- to settz() tells it to use the local
-- system timezone (settz("LOCAL") ? )
-- (internationalization problems?)
int yearlength(int, int) [see comment below]
Not included are:
long timezone; /* yuck */
int daylight; /* yuck */
int dysize(int) [see comment below]
char* tzname[2] /* too limited */
timezone()
zonetime() -- I haven't seen the definition of this
HP's nl_*() functions
I have submitted a group of functions to Rich Salz for posting to
mod.sources that, while not yet complete, do deal with the many
different country-dependent changes to calendars. It is a function
that takes a Christian era year and a country id and returns the
number of days in that year for that country. yearlength() is more
thorough that dysize(). The function's current drawbacks are that
some of the dates are a bit shaky (I have on order a book from the
Vatican that I was told is the definitive source) and not all
countries from all years are represented.
2. Modification to 'struct tm'.
I agree that 'struct tm' should be modified to adequately describe
a certain time. So, three fields should be added:
struct tm {
/* all current fields */
time_t tm_tzdiff;
time_t tm_dstdiff;
char* tm_tzname;
};
The elements 'tm_tzdiff' and 'tm_dstdiff' are for informational
and, more importantly, for the mktime() function so that it can
correctly convert any 'struct tm' into a time_t. Both are set to the
time_t equivalent of zero for the structure filled in by gmtime().
'tm_tzdiff' holds the difference in seconds (or whatever time_t is
defined to hold) for the timezone difference from UTC. 'tm_dstdiff'
is the same but for daylight saving time (is there a better name
that describes the seasonal clock changes? [see note]). The 'tm_tzname'
is the name of the timezone used when filling in the structure. Its
role is informational and also serves as a guide to going from
'struct tm' to a time_t.
[note: the city of Denver looked at the possibility of going to
a clock change for the high-pollution period of December-February
where temperature inversion and reduced auto efficiency in cold
weather result in very high carbon monoxide levels. Changing the
clocks so that Denver would, in effect, be in Central Time instead
of Mountain Time would help reduce the levels because the sunlight
would alleviate some. Consider this a LST - lung saving time :-)]
3. TZ and TIMEZONE
For current programs that use it, TZ must be kept as is. The new
variable TIMEZONE should be defined to handle the wide range of
possible and different timezones that TZ can't handle. Its format
could be open or tightly defined; I haven't given this enough thought.
Bob Devine
[ in case you're interested in what caused the havoc around here, no, the
entire place is not shutting down as happened to me at UNISYS (nee Burroughs).
ViaNetix just got sold to a company whose name I can't yet give out and we
changed what machine is known as 'vianet'.]
More information about the tz
mailing list