Bug 103414 - Allow decimal place commands to modify additional number formats
Summary: Allow decimal place commands to modify additional number formats
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha1+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp, topicUI
Depends on:
Blocks: Number-Format
  Show dependency treegraph
 
Reported: 2016-10-22 16:44 UTC by Yousuf Philips (jay) (retired)
Modified: 2019-06-10 14:57 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2016-10-22 16:44:49 UTC
I think it might be nice if the add decimal place and delete decimal place commands (.uno:NumberFormatIncDecimals, .uno:NumberFormatDecDecimals) also worked with additional commands like date and time number formats.

For example, if a user entered '09:00 AM', it is automatically set to number format HH:MM:SS AM/PM ('09:00:00 AM') and then it would be nice to be able to press delete decimal to change it to HH:MM AM/PM and pressing delete decimal again and it changes to HH AM/PM. It would work in a similar but reverse way when pressing add decimal, all the way to HH:MM:SS.00 AM/PM.

Adding and deleting decimals for dates would work in a similar way to add or remove the day, month, etc. (e.g. YYYY-MM-DD -> YYYY-MM -> YYYY) and it would also work with date + time combos like 'MM/DD/YY HH:MM AM/PM'.
Comment 1 V Stuart Foote 2016-10-22 17:24:47 UTC
Question would have to be if the styling of the number format for any other data classes affects its actual stored value. 

If so, then should not go that route for that data type.
Comment 2 Yousuf Philips (jay) (retired) 2016-10-22 17:34:30 UTC
(In reply to V Stuart Foote from comment #1)
> Question would have to be if the styling of the number format for any other
> data classes affects its actual stored value. 

The number format never affects the actual stored value, or a misunderstanding what you are saying.
Comment 3 Heiko Tietze 2016-10-23 08:31:36 UTC
First of all the increase/decrease function for date would be limited in contrast to numbers, which could be done easily I guess.

More relevant is the variable type of datetime values. Users can have MM-YY or YY-MM, how would you increase the precision here? And for the time part it's mostly to add seconds or not since hours alone are useless and milliseconds not so relevant for the average user (otherwise needed rather than "deciseconds" or "centiseconds").

On the other hand it's a typical task for me. Looking forward more opinions.
Comment 4 Yousuf Philips (jay) (retired) 2016-10-23 16:23:13 UTC
(In reply to Heiko Tietze from comment #3)
> First of all the increase/decrease function for date would be limited in
> contrast to numbers, which could be done easily I guess.

True.

> More relevant is the variable type of datetime values. Users can have MM-YY
> or YY-MM, how would you increase the precision here?

With YY-MM it would increase to YY-MM-DD, with MM-YY it would increase to DD-MM-YY.

> And for the time part
> it's mostly to add seconds or not since hours alone are useless and
> milliseconds not so relevant for the average user (otherwise needed rather
> than "deciseconds" or "centiseconds").

It is mainly to easily add and remove minutes, seconds. If i type '9 am', it will change the input and format it to '09:00:00 AM' (HH:MM:SS AM/PM), so easily removing the seconds and minutes is quite useful.
Comment 5 Laurent BP 2016-11-24 15:30:54 UTC
(In reply to Yousuf Philips (jay) from comment #4)
> (In reply to Heiko Tietze from comment #3)
> > First of all the increase/decrease function for date would be limited in
> > contrast to numbers, which could be done easily I guess.
> 
> True.
> 
> > More relevant is the variable type of datetime values. Users can have MM-YY
> > or YY-MM, how would you increase the precision here?
> 
> With YY-MM it would increase to YY-MM-DD, with MM-YY it would increase to
> DD-MM-YY.
According to his localization, user may expect MM-DD-YY or D-MM-YY. 

(In reply to Heiko Tietze from comment #3)
> On the other hand it's a typical task for me. Looking forward more opinions.
As I enhanced "Add/Delete decimal place" button for scientific format, I can give you some pointer if you need. See bug 88960
Comment 6 Heiko Tietze 2018-11-22 10:52:27 UTC
Reasonable request. If you add the code pointers, LBP, we get a fully qualified easyhack.
Comment 7 Laurent BP 2018-11-25 11:18:55 UTC
As said in comment 5 all pointers can be found in resolution of bug 88960
https://gerrit.libreoffice.org/14264/

void ScViewFunc::ChangeNumFmtDecimals( bool bIncrement )
https://opengrok.libreoffice.org/s?defs=ChangeNumFmtDecimals&project=core

if bIncrement ==> positive increment

Date and time formats are not treated yet.
Comment 8 Kyrama Styliani 2019-01-29 17:05:21 UTC
I'm interested to work on this with 2 co-workers of mine. I'm not sure which function displays the dialog window to add/delete decimal places but I hope I will find it. If someone knows the function, please let me know.
I have started working on that so I am assigning this to me.
Comment 9 Xisco Faulí 2019-03-02 03:48:35 UTC Comment hidden (obsolete)
Comment 10 Kyrama Styliani 2019-03-02 15:15:17 UTC
Yes, I'm still working on it.
I think I've done everything needed for the "Time accuracy" with my co-worker.
We still have an issue though
So we are trying to fix it and proceed with "Date"
Comment 11 Xisco Faulí 2019-03-03 03:38:26 UTC Comment hidden (obsolete)
Comment 12 Xisco Faulí 2019-06-10 14:57:39 UTC
Dear Kyrama Styliani,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.