Re: Date Trivia

In article <1qc2m9INNcl0@emory.mathcs.emory.edu> ckipp@vth1.vth.colostate.edu (Cathy Kipp) writes: > >1) Many countries switched from Gregorian to Julian calendars on a > different date, so don't expect Informix to handle it. > >2) Adding or subtracting months from a date may produce en error > (eg. Jan 30 + 1 month). "The alternative would not be logical for > everybody" is the response. > >My response to both of these is: CHOOSE AN ALTERNATIVE and DOCUMENT IT! > > <...> >does anyone else have an opinion? Consider this a vote for Cathy's position... On number 1, though, I think that what Informix currently does is relatively reasonable (i.e. it just uses the Gregorian calendar throughout). My reasoning is that if I were writing an application where this actually was an issue (which is unlikely), it wouldn't be a big deal for me to scrap Informix's date stuff, and just keep things in terms of Julian dates (i.e. number of days since 4000 something BC). Even if informix handled the Gregorian/Julian switch in one of the "right" ways, chances are high that it wouldn't be the right "right" way for me anyway, and I think that having an environment variable to specify, say, the Julian date of the the Julian to Gregorian calendar switchover (is that clear? BTW, "Julian Date" != "Julian Calendar"... Sigh) is a bit much. But then, I program almost exclusively in ESQL/C, so the "junk it and write it myself, correctly" ethic is a lot easier than for a "higher level" language like 4gl. I think there's a much stronger case for #2... What's the point of being able to say "+ 1 month" if it blows up sometimes? That forces everybody to, once again, junk Informix's implementation and write their own. But then, I don't particularly see the point of being able to say things like "+ 1 month"... Just give me a base language powerful enough to cleanly implement that myself, if I need it! (But then, some people actually _like_ cars with automatic electronic outside relative humidity meters built into the dash. And ADA.) I'm just glad that at least nobody's tried to build the concept of "working days" into SQL... Imagine the internationalization issues there! -- Bill Foote bill@pds.com PDS Corp, Los Angeles, CA USA uunet!promdist!bill