Hi Kohei, On Friday, 2007-12-07 10:09:50 -0500, Kohei Yoshida wrote:
> The rough idea I've just come up with is to do what web applications do: > provide a date input box. This way Calc also knows that the user is > about to enter a date, and try not to even parse an input as a date if > the date input box is not used Argh, no, I would hate that. I don't want be forced to use a dialog to be able to enter dates. As soon as I wanted to enter more than one date I'd just wish to kick it away. > or be more strict about what format is > considered a date in that scenario. This is what we need. > That would also allow us to > localize the date format too without causing too much headache. The date input format actually is halfly localized, the YMD order and separator are taken from the locale, but the parser accepts other separators [-./] as well. An additional problem is that, for example, US folks like to write 12/10 for Dez-10 current year, Germans wouldn't expect 10.12 to get parsed as a date, which it currently is, but 10.12. instead (note the trailing dot). And of course you want ISO 8601 yyyy-mm-dd always to be parsed in any locale, and probably also 12-10. Heck, and you want "Monday, December 10, 2007" be parsed as well. And you want input to be parsed in the same format that the cell is displayed with, if possible. What's still missing is input in other calendar systems than Gregorian for several reasons, even if output works fine. So, "localize without causing too much headache" doesn't apply at all, that would need date input rules from locale data. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks.
pgp7xeM7c3dju.pgp
Description: PGP signature
