After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 527392 - Editing of time values
Editing of time values
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: GUI
1.8.x
Other All
: Normal minor
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2008-04-10 18:11 UTC by Dominik
Modified: 2008-04-11 17:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dominik 2008-04-10 18:11:40 UTC
I need to deal with fractions of seconds and then I try to use custom format mm:ss,00 the app behaves rather unhandy. Every time i try to edit cell's content gnumeric tends to round the number to one places after dot rather than too.
It would be nice to have a special format for 1/100 of seconds or more flexibility in defining own formats.

Other information:
Comment 1 Andreas J. Guelzow 2008-04-10 18:43:12 UTC
mm:ss.00 should work (in C locale) but there seems to be something badly messed up when editing cells formatted in such a way, but I haven't tried most recent svn yet.
Comment 2 Morten Welinder 2008-04-10 19:34:01 UTC
Could you guys please be incredible specific as to what you see?
The only problem I see is this:

1. Enter 11:22.1234   [note: >3 decimals for seconds]
2. Press F2.

Gnumeric guesses a time format of "hh:mm:ss.0000" for editing, but that
format is invalid according to goffice:

	/* The actual limit is debatable.  This is what XL does.  */
	if (n > 3)
		goto error;
Comment 3 Andreas J. Guelzow 2008-04-10 21:17:00 UTC
In a pretty recent svn version I have the following behaviour (note that it is not 100% consistent):

enter 1.2345 in a cell
select the cell and format it to mm.ss.00
you see 37:40.80  which is probably expected and correct.
select the cell
click in the edit box
you now see 1.2345 which is also expected
now click the "finish editing button" or type the enter key
the cell now shows 00:00:00

reediting the cell only shows 00:00:00
what happened to 1.2345?

at home (probably 1.7.13 or so) I see all differnet numbers showing up in the edit box.... 



Comment 4 Andreas J. Guelzow 2008-04-10 21:18:58 UTC
oh, if you start with 12345.6789 then after a few editing rounds you get to 00:17.00

:-)
Comment 5 Morten Welinder 2008-04-11 11:03:40 UTC
I have fixed a number of problems, including exceeding the number of decimals
that GOFormat feels like handling.

There is still room for improvement, but if you really format the value
1.2345 as hh:mm:ss, then there is no string we can place in the edit buffer
that will not change the value.  At the very least you will lose the 1.
Comment 6 Morten Welinder 2008-04-11 13:46:03 UTC
Things are better now.

This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
Comment 7 Andreas J. Guelzow 2008-04-11 14:18:41 UTC
Morten (comment #5).

I don't understand the "if you really format the value
1.2345 as hh:mm:ss, then there is no string we can place in the edit buffer
that will not change the value."

Since I entered 1.2345 I would expect to see 1.2345 in the edit buffer. In fact If I enter that data (without leaving the location, ie. finish entering by clicking on the checkmark), for mat as hh:mm:ss and then start editing the cell again then the edit field contains as expected 1.2345.

I don't understand why we enter the _formatted_ string in the edit field. We should keep the entered information and edit that one!!  
Comment 8 Morten Welinder 2008-04-11 14:56:58 UTC
> We should keep the entered information and edit that one!!  

That comes up from time to time, but it does not work.  I enter "1.234"
in a cell and send it to you.  You change that to "1.235" and, voila!,
the value got 1000 times bigger or smaller because of comma/period
differences in meaning.  It is worse for dates.  (Add to that, that
we often do not have an entered_text for a cell value: import, paste-
as-value, ...)

So we have have to interpret at the time of entry.  They way we interpret
depends on the current format in the cell which is why we can interpret
11:22 as 11:22:00 in a hh-mm-ss cell, but as 00:11:22 in a mm-ss cell.
We also use the format to distinguish between dates and fractions, for
example.

So we have...

    newvalue = interpret(entered_text,format)

and the task at edit time is to create such an entered_text.  Sometimes,
for example for 1.2345, which is not a valid hh-mm-ss value, there is no
entered_text that we can create to get our value back.  (Actually, in this
case I think we get 29:xx:xx and luck out.)  the problem typically occurs
if you enter a value and then format the cell to something that does not
fit the value.  Enter 42 and format as text, for example, and there is
no string that will give you the number 42 back.
Comment 9 Andreas J. Guelzow 2008-04-11 15:48:07 UTC
If I enter 0.25 and format it as a 0.0, I don't loose the information. 

If we had a specifc time or date value type I would understand that dates and times behave differently, but we do not have a separate type, our dates and values are numbers.

If we import we do have an "entered text": what ever we imported which may be different from what we display. If I paste-as-value I enter the value as it is currently displayed (I would think).
Comment 10 Morten Welinder 2008-04-11 17:38:04 UTC
I don't think "0xee807fdea" is going to be popular as an entered text, but
something like that is what we get from most import formats, such as xls.
From .gnumeric we have happen to have a human-readable string, but in
C locale and thus useless as a string for the user to edit.

For paste-as-value, and other cases where values are computed instead of
entered, we cannot use the string we display.  That is rounded.

The bottom line of that is: we do not always have an entered string and
in lots of cases were are going to have to make one up, which is precisely
what we do on-demand when you hit F2.  The idea that we can carry entered
strings around is doomed.  It was tried and it failed spectacularly.

So if you are aiming at having something changed, you should put the energy
into telling me how to synthesize the entered string from a given Gnumeric
value, i.e., a gnm_float/bool/string/etc.  The constraints are...

1. When feasible, people want dates/times/fractions to be displayed and
   edited in a sensible way.  We can't just show 37000 for a date.

2. People like flexible input.  For example, a date cell should accept
   "25.2" as meaning "February 25, current year".  (Assuming the cell
   has day before month.)  Note, btw., that after you enter such a value,
   the year is set in stone.  You do not want to see just "25.2" after
   pressing F2 a year later.

3. The synthesized strings should not be different from what a user could
   enter.  In other words, "25.2" should mean precisely one thing no matter
   whether it was synthesized or typed.

4. We would like F2+Enter to be a no-op if at all possible.


We don't currently achieve (4), but we could get there by using a string
like "#1.2345" for an out-of-range time field, for example.  Not pretty.
Comment 11 Morten Welinder 2008-04-11 17:47:42 UTC
Oh, and try this:

1. Format A1 as "mm/d"
2. Enter "1/2" into A1.  (You get 01/2, current year.)
3. Re-format A1 as fraction "# ?/?".
4. Press F2.

You _really_ don't want 1/2 to show up in the edit line.  It will (and
should, IMHO) be interpreted as a half.

Entered string would have to be tagged with the context in which they were
entered: the cell format at the time and the locale.  Maybe more.