office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office] YEARFRAC, etc.
- From: robert_weir@us.ibm.com
- To: Patrick Durusau <patrick@durusau.net>
- Date: Mon, 14 Apr 2008 17:30:21 -0400
Patrick Durusau <patrick@durusau.net> wrote
on 04/14/2008 04:53:55 PM:
> Rob,
>
> OK but if I understand David Wheeler's point, it is the case that
no one
> has reverse engineered the proper definition for YEARFRAC.
>
> So, having "spotted the problem," have you suggested a solution?
>
Microsoft should document what Excel does when it
calculates YEARFRAC and it should do it completely and unambiguously.
> Yes, a lot of other people have failed to come up with the solution,
so
> how does that observation help? None of those reporting the problem
have
> offered a solution either.
>
See above. The solution is for OOXML to document
Excel's behavior. That is the purpose of OOXML after all, as stated in
their scope clause. Since Excel is a proprietary, closed-source vendor
product, no one but Microsoft can peer inside to answer this question.
In any case, by raising the issue to your attention
I'm hoping maybe that you can use some of your contacts to get an answer
we can use. You are our SC34 liaison, right? I'd rather not
wait until October for SC34 to figure out how they want to do maintenance.
Perhaps you can enter a defect report to SC34 on this question, give
Murata-san's new ad-hoc something concrete to work with. If it will
help, I can draft the defect report, we can approve it at a future TC call,
and you can get it off to SC34 as soon as the official final text of OOXML
is released.
> Here is how to move off dead center:
>
> 1) Agree that YEARFRAC has not been fully/properly/etc. defined
> 2) Agree that both ODF and OOXML need to have the same "proper"
> definition of YEARFRAC
> 3) Either derive one ourselves or in concert with others who are
> concerned about the same issue (others being a reference to OOXML)
> 4) See that both we and anyone else with a formula standard uses the
> result of #3.
>
> Granted that doesn't provide many opportunities for clever remarks
but
> none of that is going to be found in ODF 1.2.
>
> Hopefully a good definition of YEARFRAC will be.
>
> Hope you are having a great day!
>
> Patrick
>
> robert_weir@us.ibm.com wrote:
> >
> > Keep in mind the history of these date basis definitions in OOXML.
> >
> > I first reported the problem on July 9th, 2007. This became
part of
> > the comments the US submitted along with our ballot response
in Sept.
> >
> > Ecma, in their response to the ballot comments failed to fix
the
> > problem. They botched the definitions.
> >
> > The DIS 29500 BRM in Geneva, failed to fix the definitions. For
lack
> > of time the BRM decided to accept Ecma's defective text changes.
> >
> > So what we end up with now, went 100% through the Ecma, JTC1
and SC34
> > processes. No one along the way has managed to correct
these errors.
> >
> > These errors have already been reported, botched and approved
any
> > ways. I'm not sure repetition of the same process by the
same people
> > is necessarily going to lead to great improvements.
> >
> > In any case, from the ODF 1.2 perspective, I think we have no
choice
> > but to ignore OOXML's definitions and try to reverse engineer
> > Microsoft Excel. It could be a good marketing statement
-- OOXML may
> > be better at calculating wrong leap years and incorrect footnote
> > placement like Word 95 did, but only ODF defines financial spreadsheet
> > functions in a way which is compatible with current and legacy
> > versions of Microsoft Excel.
> >
> >
> > -Rob
> >
>
> --
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]