Sorry, wrong message date at the end, should read 2007-07-04

"Jan Sax" <[EMAIL PROTECTED]> schreef in bericht news:...
> Hi Eike,
>
> "Eike Rathke" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
>
>> You're mixing up two different things: ODF file format and UI 
>> representation.
>>
>
> No. I'm talking only and specificly about DEFAULT UI representation in any 
> product developed not strictly for personal use, but jointly (and 
> heavily!) for Data Interchange as well; and thát's what we are talking 
> about when it comes to Calc.
> Since ISO 8601 formatting has been universally and globally agreed upon 
> already about half a century ago: in ANY localized version of whatever UI, 
> only THAT format should be presented as "THE" BASIC default representation 
> format.
> For decades to come, so called "localized formats" (see below) might still 
> be understood within smaller communities (e.g. nationally), but might 
> cause a lot of problems when transferred outside the borders of such 
> communities. The world doesn't stop to exist any more at such borders. 
> That's why a vast majority of right-minded people (science, education, 
> industry, government) strongly have been advocating a fast universal turn 
> around to ISO 8601 format in education and everyday use for everybody all 
> over the world.
> (Of course: what a user would change that default representation to 
> afterwards, or what specific format to be used in the context of documents 
> made for private or restricted group use, always is strictly up to that 
> user to decide. Thus, OPTIONS for obsolete formats should stay available.)
>
>> Why? Most users expect to see and edit in the format they're used to, 
>> which still is their localized format.
>>
>
> Yes and No.
> Yes. But giving in to that kind of "convenience", one would go wrong; one 
> should NEVER give in on that level. Because then, one would do nothing to
> HELP people turn around to accept and implement any Standard, Rule, Law or 
> whatever. On the contrary, one deliberately would ruin a lot of precious 
> effort. Not being a comercially driven community, the Open Community, and 
> especially developers in that Community, should realize that certain 
> educational obligations towards general community (i.e. not only the Open 
> Community itself) do exist, and thus a number of "less convenient" 
> principles should prevail over the need for optional obsolete formats.
> No. Formally, all-numeric "localized formats" don't exist at all any more, 
> and have not been existing any more for the past half a century. The only 
> valid formats existing are ISO 8601 representation and (of course: then 
> localized because of language dependency) full date with month NAMED. If 
> they don't know that already, local users should be made aware of that 
> fact: see Yes.
> (That's why I suggested for ALL general and localized formatting: at least 
> in the Formula bar, NEVER show anything else but format "yyyy-mm-dd".)
>
>> You might want to discuss this in-depth with the User Experience team 
>> though.
>>
>
> Only if still necessary, I would. As if still necessary, I would also 
> discuss it with developers as well. But I think developers already should 
> have been very aware of this issue for a number of decades, as the UEteam 
> should have since the very start of the OO/Calc project. That's why I 
> addressed my original message to everybody who might start feeling 
> concerned after the issue being brouhgt to attention clearly.
> (In case anybody would like to discuss this issue or specific details with 
> me outside this Questions forum: you're welcome.)
>
> All this on your mind now, please think again about significance and 
> impact of suggestions in my original message dated 2007-07-02 and 
> additional info dated 2007-04-24.
> Regards,
> Jan
>
>
>
> "Eike Rathke" <[EMAIL PROTECTED]> schreef in bericht
> news:[EMAIL PROTECTED]
>> Hi Jan,
>>
>> On Wednesday, 2007-07-04 02:03:29 +0200, Jan Sax wrote:
>>
>>> But in my opinion, that reproach would implicate that OO would have to
>>> behave better than OOXML as far as ISO 8601 is concerned. If that would
>>> be
>>> true, I fail to understand why ISO 8601 complete extended date
>>> representation isn't DEFAULT in all OOo general and local versions.
>>
>> You're mixing up two different things: ODF file format and UI
>> representation. In ODF the date/time values _are_ stored in ISO 8601
>> format. How they are represented to the user depends on the locale she
>> works in and the number (date) format assigned to display the value.
>>
>>> Of course, any user should be able to change CELL level format to
>>> localized
>>> date format representation. But basically, the ONLY correct formula bar
>>> representation should ALWAYS be according to ISO 8601 complete extended
>>> format.
>>
>> Why? Most users expect to see and edit in the format they're used to,
>> which still is their localized format. You might want to discuss this
>> in-depth with the User Experience team though.
>>
>>> As should be the DEFAULT cell format in any localized OO version
>>> BEFORE intentionally applying a localized format. For unambiguous data:
>>> the
>>> latter only to be chosen if one is sure that ones data never would cross
>>> national boundaries.
>>
>> The data is unambiguous, as stored in an unambiguous ISO 8601 format.
>> For unambiguous display it usually is sufficient to not assign any
>> locale specific date format, the default display format chosen then
>> simply is that of the system the user works on or of the default locale
>> chosen in the application under Tools -> Options -> Language Settings.
>>
>>  Eike
>>
>> -- 
>> OOo/SO Calc core developer. Number formatter stricken i18n
>> transpositionizer.
>> OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
>> Please don't send personal mail to this [EMAIL PROTECTED] account, which I 
>> use
>> for
>> mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED]
>> Thanks.
>
>
>
>
>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to