Hi Eike, On Mon, 2007-12-10 at 13:44 +0100, Eike Rathke wrote: > 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.
Just to be clear, I mentioned such date input dialog as an optional feature. > > 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. You just described how complex it is to parse a date input, and that's exactly my point. :-) And the point I was trying to make with my date input box idea was to give the user a way to bypass that complex parsing process when it's needed (e.g. when the parser parses it incorrectly). With a date input box, the user input is already known to be a date, which would reduce the amount of "guessing" the parser needs to perform. > So, "localize without causing too much headache" doesn't apply at all, > that would need date input rules from locale data. If we can in some way 1) introduce an input context where the user input is guaranteed to be a date (such as a specialized date input box), 2) optionally turn off parsing the input as date for all the other cases, or clearly define what will be parsed as date and make it configurable then it would at least reduce the amount of headache, in theory. It appears that we all agree on 2). As for 1), I also agree that forcing everybody to use it would be a bad idea (I'd hate that too). But I think the idea itself, and the problem it tries to address should be kept in the back of our mind when developing the requirement for this enhancement idea. Just my opinion. Kohei --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
