Amendment 2: Date range for the 1904 date base?

[Chris Rae]

To answer the side issue - neither of these date bases allows the leap year bug in strict (at least, after this Amendment they don't!); in transitional the 1900 date base does have a leap year bug.

Regarding the storage of serial values, it's a good point and I'll have a chat with Gareth. I think we may have already covered this elsewhere in the numeric precision sections of 29500 but I'll check.

Happy Wednesdays,

Chris

-----Original Message-----
From: Rick Jelliffe [mailto:rjelliffe at allette.com.au] 
Sent: 20 July 2010 23:57
To: e-SC34-WG4 at ecma-international.org
Subject: Re: Amendment 2: Date range for the 1904 date base?

On 07/21/2010 04:01, Chris Rae wrote:
> Hi Rick et al - I think we (WG4) were generally heading towards being agnostic between 1904 and 1900 date base, so I'd rather not discourage its use. ODF allows an arbitrary date base to be set, so I think we have a precedent for allowing more than one. However, it's possible we weren't agreed on that so I don't want to speak for everyone.
>    
Side issue: does either of these date bases encourage (witting or
unwitting) retention of the 1900 leap year date bug? I have lost track of what the status quo of that is, I am afraid.
> As far as the range limits go, I might not be understanding quite right but I think we are already limiting them by value space. We're just limiting them by the "date" value space (i.e. years, months, days) rather than the value space of the serial numbers they turn into. I would strongly prefer limiting the date ranges in terms of the real dates, mainly because it's a lot easier for an implementer to parse user-entered dates and times when there are precise value-space limits on the dates and times themselves. It also echoes the profiling done by other implementers of date subsets (SQL, etc) - there's a bit more info about that in the presentation that Gareth and I showed to WG4 (http://www.itscj.ipsj.or.jp/sc34/wg4/archive/sc34-wg4-2010-0114.zip).
>    
  Being agnostic as to base and limiting the date-index value-space to some number based on the equivalent lexical spaces of the components of a real date is fine, to explain the rationale for the restriction. But it does not preclude providing information about which storage types (how many bits or octets etc) are necessary for representing those numbers.

Cheers
Rick Jelliffe