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'.]