Subject: OOo / StarSuite8: Calc: Date Format
Of course, using a Dutch Calc version, I might format any cell containing a
calendar date with language selection Hungarian or Lithuanian. But I don't
think that's the intention of the "open" community. I searched your "Knowledge
Base" for answers and solutions, but didn't find any. Maybe you could help?
Moreover, I don't know whether this issue goes for more existing (both
universal and local) OO versions, or is specific only for StarSuite8 in general
or StarSuite8/Dutch in particular which I'm using right now (newbee user).
There could never be anything wrong with representing a calendar date
unambiguously using both a named month and a 4-digit year number. So either:
day in 1 or 2 decimal digits (leading zero preferred), named month, year in 4
decimal digits, or the other way around: year in 4 decimal digits, named month,
day in 1 or 2 decimal digits (leading zero preferred), couldn't possibly be
misinterpreted ever. Nor could US common practice: named month, day in 1 or 2
decimal digits (leading zero preferred), year in 4 decimal digits.
But isn't International Standard ISO 8601 accepted by the "open" community as
conditio sine qua non? And consequently implemented in OO?
Please note that probably about half of the worlds population actually uses
calendar date representations according to (or at least similar to) what is
defined by this globally adopted and implemented International Standard. It
defines:
- descending date element order year-month-day: whenever in a calendar date the
element "month" is represented numerically (decimal digits), the date
representation (complete representation, extended format) shall read:
yyyy-mm-dd;
- only hyphen ("minus sign") shall be used as separator for all-numerically
represented date elements.
For ALL existing (and future) Calc versions world wide:
If ISO 8601 is accepted by the "open" community:
- at least in the Calc formula bar, shouldn't any date input ALWAYS, in any
version, show unambiguously either full date (e.g. 02 August 2007), or ISO 8601
complete extended date representation (e.g. 2007-08-02)? (note: of course,
month name "August" might be language dependent, and might be truncated
unambiguously to 3 alphanumeric characters);
- by default, shouldn't any date representation in any cell basically show ISO
8601 complete extended date representation, regardless of actual Calc version?
(note: basically in this context means: if not formatting of that cell has been
changed intentionally by the user);
- by default, shouldn't any input "a-b-c" basically always be recognized as the
valid complete calendar date "y-m-d", regardless of actual Calc version? (note:
a, b and c of course to be valid calendar date element values);
- consequently, by default, shouldn't any input "a-b" basically always be
recognized as the valid (truncated representation) calendar date "m-d of the
present year", regardless of actual Calc version?
- shouldn't a General Setting for OO as a whole pre-selecting ISO 8601
formatting for any related data in all kinds of documents be appropriate?
When searching for correct representations in Opmaak > Cellen > Getallen >
Datum > Taal in my Calc version, I found only 2 language settings for which by
default I got complete correct results: Hungarian and Lithuanian; and 3 further
language settings which returned at least acceptable results (formula bar: year
as "yyyy", cell: year default as "yy"; element separator hyphen): Esperanto,
French (Canada) and Swedish. Besides, I found quite a lot of other language
settings with correct date element order but different date element separator
(e.g. Chinese, Japanese and more Asian languages, several African languages).
Note: very strange: when selecting French (Canada), "yy-mm-dd" is used, wheras
English (Canada) results in "dd/mm/yy"! Does that truly reflect nationwide
Canadian common practices?
I hope you'll be able to clear this issue.
Regards,
Jan Sax
Tetrodestraat 44
NL - 5623 EP Eindhoven
tel. +31 40 2441913
e-mail: [EMAIL PROTECTED]
