OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] Portable language?


David,

On 3/30/2010 3:20 PM, David A. Wheeler wrote:
> Patrick Durusau :
>    
>> I am cleaning up the last of the "portable" language issues and ran
>>      
> across: Creators of portable documents shall use conversion functions (such as
> VALUE, DATE, DATEVALUE, TIME, and TIMEVALUE) when this specification does
> not require such conversions. Note that some of these functions are
> locale-dependent, and their use can result in documents not working the
> same way in different locales.
>    
>> Sorry, that sounds like a contradiction to me.
>> Shall use conversion functions --- when this specification does not
>>      
> require such conversions.???
>    
>> I am sure I am simply missing the context but even typing it into this
>>      
> email did not help (it usually does).
>    
>> Is this meant to say that explicit conversions should be used? As opposed
>>      
> to relying upon automatic conversion?
>    
>> If so, that isn't what this says. Or at least it doesn't say it clearly.
>>      
> Hmm, I can tell you what that text was *trying* to address, and I agree that it doesn't do it :-).
>
> The issues here are that:
> * OpenFormula does not mandate a specific epoch ("start of time" value), yet people *can* insert a number and later use it as a date.  Thus, you can't portably insert the number 10000 in a spreadsheet, use it as a date, and expect that it'll have the same result regardless of the epoch value.
> * Many text date representations are locale-specific, e.g., 01/02/2000 might be January 2 or February 1.  So, you can't portably insert the string "01/02/2000" in a spreadsheet, use it as a date, and expect it'll have the same result regardless of locale.
>
> So, if you want a "portable document" you need to use expressions that are unambiguous and do *NOT* depend on epoch or locale values.  So for example, a date obtained from DATE, or by using DATEVALUE and passing in an ISO format ("YYYY-MM-DD") string, do not depend on epoch or locale values.
>
>    
Wow! I had no idea that was want you wanted!
> Now the challenge is to find a way to *express* this constraint.
>
> Does that help?
>
>    
Well, it helps me understand the issue! ;-)

OK, so the purpose of the language actually was to encourage use of the 
ISO 8601 format for reliable interchange.

Yes? (Noting that DATE isn't required to accept ISO 8601 dates as say 
DATEVALUE must accept.)

Nor is anyone required to enter dates as ISO 8601 dates. Yes?

OK, why not say:

"Note: Interoperability is improved by the use of ISO 8601 date formats 
because dates in that format do not rely upon epoch or local-specific 
settings."

That way we don't have to say how the dates get into ISO 8601 date 
format, they could be entered that way, or converted from some other 
representation, be the result of an expression, etc. All we as saying is 
that using that format improves interoperability.

Does that work?

Hope you are having a great day!

Patrick



> --- David A. Wheeler
>
>    

-- 
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]