Re: [office-formula] Who's doing what this week, Redux (includinga request to Stefan Nikolas)

["David A. Wheeler" <dwheeler@dwheeler.com>]

David A. Wheeler wrote:
> > Robert Weir has volunteered to do NETWORKDAYS and WORKDAY, since they
> > have the same I18N issues.  Basically, he's going to need to add an
> > additional optional parameter to handle internationalization

Eike Rathke responded:
> If we add a parameter that no application is supporintg yet I suggest to
> define it the way that if the parameter is not given comply with the
> Ecma/Excel definition. Eases interoperability.

Oh, absolutely, that was the reason I want it optional.  Sorry I didn't make that clear.  It's really not just Ecma/Excel; I think everyone does it the same way.

> > - not EVERYONE's weekend is Saturday/Sunday.  I see two major options:
> > (1) a parameter saying which day of the week begins a two-day weekend,
> > or
...
> > (2) a parameter that's a boolean representation of the days of the
> > week that are to be considered non-workdays.  Option #2 is more
> > flexible, but also is harder to implement and explain... does anyone
> > care which way he goes?
> 
Eike adds a #3:
> It may also be necessary to include half days, as in "Saturday is half
> day off, Sunday one day". The most flexible IMHO would be to have an
> array with a factor in the range [0,1] for each weekday, if that's not
> considered overkill.

Eek.  Actually, you can even pile on the overkill further; many people in the U.S. work in 2-week cycles, so they work 5 days one week and 4 days in the alternate week.  That would add yet another option:

#4: The new optional parameter accepts an array; if 14 days instead of 7, it that describes a two-week cycle.

I think #3 and #4 are more flexible but would be much harder to use.  You could partly address that yet another option:

#5: Merge #2, #3, #4. Basically, detect if the new parameter is a scalar number, and if so, interpret as #2. If the new param is array/multi-cell range, then interpret as #3 or #4 (depending on its length).  That might make common cases easier to use, and still be very flexible - but it's more work to implement.

I have to admit that #3, #4, and #5 seem awfully like overkill to me. Does anyone have an opinion on what is best for our purposes?

--- David A. Wheeler