[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-formula] Conflict between Part 1 and Part 2
On Fri, 2010-02-05 at 07:29 -0700, robert_weir@us.ibm.com wrote: > "Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 02/04/2010 > 07:05:08 PM: > > > > > RE: [office-formula] Conflict between Part 1 and Part 2 > > > > On Thu, 2010-02-04 at 16:41 -0700, Eric Patterson wrote: > > > I think that puts us back where we started. We use the null-date and > > > acknowledge that dates between 1-Jan and 28-Feb may be different. No > > > further attributes are needed. Anyone disagree to this strategy? > > > > I do. > > > > I think an application should be able to legitimately discover whether a > > file it opens was created under the assumption that there is a skip in > > the number->date mapping before 1900/3/1 or not. > > > > So what are you proposing? An attribute that indicates whether the > authoring application had the *1900-02-29 date? What behavior would be > required by evaluators who process a formula where that attribute was set > to true? Or are you seeing this as being a "hint" only, with no required > behavior? I would propose an attribute that indicates whether the authoring application had a skip between 1900-02-29 and 1900-03-01, ie. whether (1900-03-01 minus 1900-02-29) is 1 or 2. > > There are other date-related bugs in spreadsheets. If I type 0 into Excel > and format it as a date, it displays "1/0/1900". Do we need an attribute > for that as well? Gnumeric does _not_ have the 1900-02-29 date, nevertheless it has a skip, ie. the above difference is 2. You seem to claim that the only reasonable number to date mapping or date to number mapping is such that (1900-03-01 minus 1900-02-29) is 1. That is simply false. There are many reasonable ones, and specifically a small number currently in use. I object to the characterization of any choice other than one's favourite one as a "bug". I am usually told that "we can't do that because implementation are doing it differently". As a consequence we seem to include such nonsense functions as CHITEST and provide for duplicate versions of lots of other functions. Either we worry about current implementations or we don't. As far as the expected behaviour is concerned, a combination of true null-date plus an attribute about a skip would allow evaluators to correctly deal with post 1900-3-1 dates and warn a user about potential problems with pre 1900-3-1 dates. As long as users use number <-> date conversions in their calculations there will always be a portability issue. At least we can provide the tools to have users advised about them. Andreas > > -Rob > > > > As far as I am concerned having the standard suggest that one falsifies > > the null-date when saving is unacceptable. > > > > If for whatever reason people object to discoverability and want the > > difference in serial numbers for dates prior to 1900/3/1, then the > > null-date ought to be defined differently, by perhaps giving the date > > corresponding to serial=100. > > > > Andreas > > > > > > -- > > Andreas J. Guelzow <andreas.guelzow@concordia.ab.ca> > > Concordia University College of Alberta > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]