Draft for review: ISO 8601 date work on IS 29500

[Jesper Lund Stocholm]

Hello all,

I actually used "formulas" to begin with but changed it to "functions" a
bit down the road. I have absolutely no strong feelings about either or
the other.

My reason for using "functions" is that we (CIBER) is in the "doc
generation business" and not in the "doc consumption business" as
Microsoft and others are. So we will likely be doing much more
generation stuff than consumption stuff.

A pretty straight-forward use-case would be for us to generate a
spreadsheet based on some dates. So we'd have

Column1    | Column2
-----------------------
2010-01-02 | 2010-01-03
2010-01-02 | 2010-01-03
2010-03-12 | 2010-03-14


We would then add a third column containing the difference between the
first two

Column1	| Column2    | Column3
---------------------------------
2010-01-02	| 2010-01-03 | 1
2010-01-02	| 2010-01-03 | 1
2010-03-12	| 2010-03-14 | 2


The markup of the cells of third column would be something like

<Cell r="C3">
  <v>1</v>
  <f>C2-C1</f>
</Cell>

At no point we'd be converting the dates of the first columns to serial
values - and heck, we might even skip the <v>-element itself (I am
pretty sure it is not required). I realize that the tool we'd use to
subtract the dates might internally do a conversion, but as a developer,
I am quite oblivious to this (and should be, really).

So I think The "functions"-word is better (as functions like DATEDIFF
etc take serial values as arguments) since using formulas on cells with
dates in them does not in fact require you to convert it to serial
dates.

But as I said, I do not really consider it a big deal - and I realize
what if we were in the productivity suite business, we'd likely see
things differently.

:o)



Med venlig hilsen / Best regards

Jesper Lund Stocholm

CIBER Danmark A/S
Mobil: +45 3094 5570
Email: jesper.stocholm at ciber.dk

> -----Original Message-----
> From: Chris Rae [mailto:Chris.Rae at microsoft.com]
> Sent: Thursday, July 22, 2010 7:19 PM
> To: Jesper Lund Stocholm; e-SC34-WG4 at ecma-international.org
> Cc: Horton, Gareth
> Subject: RE: Draft for review: ISO 8601 date work on IS 29500
> 
> Hi Jesper - this is a fine point and your first examples are
> compelling. However, I'd rather use "formulas" than "functions" - your
> last "C1+3" example does require the date to be converted to a serial
> (as you cannot rely on date formatting existing on the destination
> cell).
> 
> Would you be happy if we replaced "calculations" with "formulas"
> (perhaps with a reference to the formulas section)?
> 
> Chris
> 
> -----Original Message-----
> From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk]
> Sent: 21 July 2010 23:35
> To: Jesper Lund Stocholm; Chris Rae; e-SC34-WG4 at ecma-international.org
> Cc: Horton, Gareth
> Subject: RE: Draft for review: ISO 8601 date work on IS 29500
> 
> Hello all,
> 
> I was giving the document another glance (well, to be honest, I dreamt
> about this hick-up last night) and I noticed a sentence in section 2.4
> at the bottom of page 20. The text currently says:
> 
> "When used in calculations, dates and times are converted to serial
> date values"
> 
> I was writing some code the other day to parse <S> Spreadsheets, and I
> will of course need to do something with the dates. But I will
> certainly not be converting them to serial dates in my tool - even
> though determining "Number of days from Today to 'date in current
> cell'" or "Duration based on difference between date in column B and
> date in column C" or simply adding a formula as "=C1+3" with C1 being
a
> date could certainly be regarded as using dates "in calculations".
> 
> I'd suggest that the text be changed to say something like
> 
> "When used in functions specified in this specification, dates and
> times may be converted to serial date values"
> 
> I think the prose in my suggestion is more in line with the official
> ISO-lingo where the current "are converted to ..." is a bit more
> relaxed.
> 
> 
> 
> Med venlig hilsen / Best regards
> 
> Jesper Lund Stocholm
> 
> CIBER Danmark A/S
> Mobil: +45 3094 5570
> Email: jesper.stocholm at ciber.dk
> 
> 
> > -----Original Message-----
> > From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk]
> > Sent: Saturday, July 10, 2010 10:13 PM
> > To: Chris Rae; e-SC34-WG4 at ecma-international.org
> > Cc: Horton, Gareth
> > Subject: RE: Draft for review: ISO 8601 date work on IS 29500
> >
> > Hello,
> >
> > > -----Original Message-----
> > > From: Chris Rae [mailto:Chris.Rae at microsoft.com]
> > > Sent: Thursday, July 08, 2010 3:12 AM
> > > To: e-SC34-WG4 at ecma-international.org
> > > Cc: Horton, Gareth
> > > Subject: Draft for review: ISO 8601 date work on IS 29500
> > >
> > > Hi all - Gareth and I think we have got something to the point
> where
> > it
> > > can be reviewed by WG4. However - this is an early draft. The main
> > > areas of interest should be, I think, the line items in
> > "introduction".
> > > That summarises the work that we've tried to effect in this draft.
> > >
> > > The changes are shown using "faux change tracking" in the document
> -
> > > blue text is new; red strikethrough text is to be removed. The
part
> 4
> > > sections take a little while to get used to - while reading those,
> > bear
> > > in mind that Part 4 is an addendum and so adding to or removing
> from
> > it
> > > sometimes takes a little while to get used to on the eye...
> > >
> > > We'd really appreciate a deeper review from anyone with subject
> > matter
> > > expertise here.
> >
> > I think you have done a really good job on this.
> >
> > Not really being an SME on this ...
> >
> >
> >
> > A couple of typos:
> >
> > * Page 14 (XIV):
> >
> > Third paragraph in "date1904"-section has an "a" too many.
> >
> > * You state on page 5 (V) that "Dates and times are specified in
> local
> > time, with no timezone designation permitted.", but on page 21 (XXI)
> it
> > says:
> >
> > "Each unique instant in SpreadsheetML time is stored as an ISO
> > 8601-formatted string, which is made up of a date component, a time
> > component, and a timezone component."
> >
> > * A bit further down in the example:
> >
> > [Example: The time 08:30 could be represented in the following ways
> > within SpreadsheetML:
> > 08:30
> > 08:30.00
> > end example]
> >
> > I am pretty sure "08:30.00" should be "08:30:00" (last period
> exchanged
> > with at colon).
> >
> > Would it be relevant with an example containing decimals like
> > 08:30:01.250 ?
> >
> >
> > * On page 26 (XXVI) - is there any reason for the simple types
> > ST_Objects and ST_UpdateLinks in the schema to be change tracked (it
> > looks like they were added).
> >
> >
> >
> >
> > Med venlig hilsen / Best regards
> >
> > Jesper Lund Stocholm
> >
> > CIBER Danmark A/S
> > Mobil: +45 3094 5570
> > Email: jesper.stocholm at ciber.dk
> >
> >
> >
> > >
> > > The document is attached in both IS 29500 and PDF form. I'll also
> > > introduce it briefly in the WG4 call tomorrow. Gareth and I have a
> > Live
> > > Mesh folder that we use to collaborate on this - if anyone would
> like
> > > access to the original tracked-changes document, please let either
> of
> > > us know and we'll permission you to that work area (the Part 1
> > changes
> > > are 22Mb, and as such don't befit emailing).
> > >
> > > Chris