adamm@necis.UUCP (Adam Moskowitz) (04/04/89)
Yes, when I came in this morning my system tried to tell me it was an hour
earlier that it really was. Arrgh! So off I go to hack the various bits of
code to understand the new rules for DST and what do I find? A mess! I didn't
even try to clean it up - I just patched the correct magic constant and hoped
for the best. However, it brought up the following questions:
1) Does anyone know if the version of ctime (and its relatives) in
System V Release 4 have the new DST rules built into them?
2) Does anyone know if the new versions are less naive about determining
leap years? It seems the current routines only use the "year % 4 ==0"
rule.
3) Will the newest version of the date command function after the year
1999? All the versions I can find (BSD and sVr2.x) croak on non-
twentieth-century years.
4) Was anything done to make it easier to rewrite the rules for DST?
(In other words, I don't want to recompile ctime and relink every
program that uses it the next time the congresscritters decide to
pass useless legislation.)
Email replies are preferred; I'll summarize if I get anything worthwhile.
--
Adam S. Moskowitz ...!(backbone)!{necntc,encore}!necis!adamm
"Bon-hommy," went on Eeyore gloomily. "French word meaning
bonhommy," he explained. "I'm not complaining, but There It Is."shapiro@rb-dc1.UUCP (Mike Shapiro) (04/05/89)
In article <1006@necis.UUCP> adamm@necis.UUCP (Adam Moskowitz) writes: ... > 4) Was anything done to make it easier to rewrite the rules for DST? > (In other words, I don't want to recompile ctime and relink every > program that uses it the next time the congresscritters decide to > pass useless legislation.) ... A couple of years ago, I looked at this problem while evaluating the design of a ``time and attendance'' system (time clock recording system) for a firm which produces business systems. My solution at that time was to have a table in a file indicating the dates that daylight savings time would begin and end. It still seems to me the best solution. I note on today's "Morning Edition" on PBS the discussion of a possible change in the daylight savings time laws which would extend the daylight time IN THE PACIFIC TIME ZONE ONLY until after the election in presidential election years. Now let's try to come up with a programmable algorithm for that! -- Michael Shapiro, Gould/General Systems Division (soon to be Encore) 15378 Avenue of Science, San Diego, CA 92128 (619)485-0910 UUCP: ...sdcsvax!ncr-sd!rb-dc1!shapiro
gwyn@smoke.BRL.MIL (Doug Gwyn ) (04/06/89)
In article <439@rb-dc1.UUCP> shapiro@rb-dc1.SanDiego.gould.UUCP (Michael Shapiro) writes: >In article <1006@necis.UUCP> adamm@necis.UUCP (Adam Moskowitz) writes: >> 4) Was anything done to make it easier to rewrite the rules for DST? >A couple of years ago, I looked at this problem ... >Now let's try to come up with a programmable algorithm for that! ??? Where have you guys been? A completely table-driven implementation of the time conversion routines (using external text files containing the rules, which may be exceedingly baroque) was developed and placed into the public domain well over a year ago. elsie!ado seemed to be the chief instigator of this and is now working on an improved version.
Makey@LOGICON.ARPA (Jeff Makey) (04/07/89)
In article <9994@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >A completely table-driven implementation >of the time conversion routines (using external text files containing >the rules, which may be exceedingly baroque) was developed and placed >into the public domain well over a year ago. Has anyone ported this package (or any other) to VMS? After 10+ years of development, VMS *still* has no concept of time zones nor of daylight savings time. I have noted that the DEC implementations of time() and ftime() that come with VAXC are broken (since they return local time instead of Greenwich Mean Time), and gmtime() just returns a null pointer. I suspect that most VMS system managers have better things to do than to reboot their systems twice a year just to reset the clock. This topic started in comp.unix.questions, but followups are directed to comp.os.vms since I am now only concerned with VMS. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: Logicon doesn't even know we're running news. Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makey
dg@lakart.UUCP (David Goodenough) (04/10/89)
From article <1006@necis.UUCP>, by adamm@necis.UUCP (Adam Moskowitz): > 2) Does anyone know if the new versions are less naive about determining > leap years? It seems the current routines only use the "year % 4 ==0" > rule. Do you _REALLY_ think this code will still be running on Feb 28, 2100. No I didn't think so. For the forseeable future, the naive method works just fine. :-) -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
rja@edison.GE.COM (rja) (04/16/89)
From article <1006@necis.UUCP>, by adamm@necis.UUCP (Adam Moskowitz): > 2) Does anyone know if the new versions are less naive about determining > leap years? It seems the current routines only use the "year % 4 ==0" > rule. Fixed by POSIX as I recall. (POSIX == IEEE 1003.1 standard in this case).
guy@auspex.auspex.com (Guy Harris) (04/18/89)
> > 2) Does anyone know if the new versions are less naive about determining > > leap years? It seems the current routines only use the "year % 4 ==0" > > rule. > >Fixed by POSIX as I recall. (POSIX == IEEE 1003.1 standard in this case). Nope. POSIX just refers to ANSI C for the descriptions of "localtime" and "mktime", and the (d)(p)ANS doesn't say anything about how those routines should decide what a leap year is. It's a quality-of-implementation issue.
abcscnge@csuna.csun.edu (Scott "The Pseudo-Hacker" Neugroschl) (04/30/89)
In article <1918@edison.GE.COM> rja@edison.GE.COM (rja) writes: > > From article <1006@necis.UUCP>, by adamm@necis.UUCP (Adam Moskowitz): > > 2) Does anyone know if the new versions are less naive about determining > > leap years? It seems the current routines only use the "year % 4 ==0" > > rule. > >Fixed by POSIX as I recall. (POSIX == IEEE 1003.1 standard in this case). While I like Unix as much as the NeXT guy (pun intended), does anyone in this group REALLY believe that it will still be around in the year 2100? Come on, guys, and get a clue!!!!!!! -- Scott "The Pseudo-Hacker" Neugroschl UUCP: ...!sm.unisys.com!csun!csuna.csun.edu!abcscnge -- unless explicitly stated above, this article not for use by rec.humor.funny -- Disclaimers? We don't need no stinking disclaimers!!!
khera@juliet.cs.duke.edu (Vick Khera) (05/01/89)
In article <1937@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott Neugroschl) writes: >While I like Unix as much as the NeXT guy (pun intended), does anyone in >this group REALLY believe that it will still be around in the year 2100? >Come on, guys, and get a clue!!!!!!! > >Scott "The Pseudo-Hacker" Neugroschl >UUCP: ...!sm.unisys.com!csun!csuna.csun.edu!abcscnge I believe that you meant the year 2000, not 2100 as not being a leap year. But, we know that Unix was designed to ``time-out'' at Jan 18, 2038 at 10:14:08PM. At least that is when the 32 bit time value runs out of room. Vick. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ARPA: khera@cs.duke.edu Department of Computer Science CSNET: khera@duke Duke University UUCP: {mcnc,decvax}!duke!khera Durham, NC 27706
tale@pawl.rpi.edu (David C Lawrence) (05/01/89)
In <14353@duke.cs.duke.edu> khera@juliet.cs.duke.edu (Vick Khera) writes:
Vick> I believe that you meant the year 2000, not 2100 as not being a
Vick> leap year.
Check your leap-year equations again. The year 2000 most certainly
will be a leap year as it is evenly divisible by 400.
--
tale@rpitsmts.bitnet, tale%mts@itsgw.rpi.edu, tale@pawl.rpi.eduwhh@PacBell.COM (Wilson Heydt) (05/01/89)
In article <14353@duke.cs.duke.edu>, khera@juliet.cs.duke.edu (Vick Khera) writes: > In article <1937@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott Neugroschl) writes: > >While I like Unix as much as the NeXT guy (pun intended), does anyone in > >this group REALLY believe that it will still be around in the year 2100? > >Come on, guys, and get a clue!!!!!!! Correct questions! > I believe that you meant the year 2000, not 2100 as not being a leap year. Wrong--check with pope Gregory XIII (name is right, not sure of number). The *real* trick is to know under what circumstances 1900 *was* a leap year. (Likewise, but of less practical use, 1700 and 1800.) --Hal ========================================================================= Hal Heydt | In the old days, we had wooden Analyst, Pacific*Bell | ships sailed by iron men. Now 415-645-7708 | we have steel ships and block- whh@pbhya.PacBell.COM | heads running them. --Capt. D. Seymour
gil@banyan.UUCP (Gil Pilz@Eng@Banyan) (05/02/89)
In article <1937@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott Neugroschl) writes: >In article <1918@edison.GE.COM> rja@edison.GE.COM (rja) writes: >> >> From article <1006@necis.UUCP>, by adamm@necis.UUCP (Adam Moskowitz): >> > 2) Does anyone know if the new versions are less naive about determining >> > leap years? It seems the current routines only use the "year % 4 ==0" >> > rule. >> >>Fixed by POSIX as I recall. (POSIX == IEEE 1003.1 standard in this case). > >While I like Unix as much as the NeXT guy (pun intended), does anyone in >this group REALLY believe that it will still be around in the year 2100? >Come on, guys, and get a clue!!!!!!! You misunderstand. UNIX may not be around in the year 2100 but there are virtual-time implementations of UNIX that have the ability to act _as_ _if_ _it_ _where_ 2100 and these need to worry about leapyears etc. Now granted, the usual use of a virtual-time machine is to operate in past-mode virtual-time (thus enabling you to get those critical projects done on time even though it took you three weeks longer than scheduled), it still doesn't make sense to cut corners in such critical areas. Delbert de la Platz @ The Society for Right Justification (gil@banyan.com)