[EuiSuperDatePicker] Does not properly restore relative dates

[matt-moses]

SuperDatePicker does not properly restore relative dates

Steps to reproduce:

1. Go to https://elastic.github.io/eui/#/forms/super-date-picker and to the first time picker on that page
2. Click start date to edit the start date and enter 15 months ago
   
3. Observe SuperDatePicker puts human friendly desc in start date of ~ 1 year ago which is handy.
4. Click Update
5. Observe the time picker reflects 15 months ago just fine.
   
6. Click to edit the start date again
7. Observe that 1 year ago is populate in the time picker GUI instead of 15 months ago. Note the underlying date is still correct (verify this by looking at the absolute date at the bottom of the picker).
   
8. As a user I would expect it to restore 15 months ago and if I manually fix it myself it causes the dialog to get stuck in "update mode" (see SuperDatePicker gets stuck in "update" mode. #4025)

[JasonStoltz]

We're thinking that a viable solution to this may be to add a prop which turns off rounding (for #5752 as well).

[markov00]

Hi @JasonStoltz @cee-chen after seeing this elastic/kibana#143157 I think it would be great if you could re-prioritize this task. The proposed solution (adding a prop to disable rounding) sounds good to me.
As stated here elastic/kibana#143157 (comment) we are not gaining much when we round the values (in UI terms, probably just a couple of characters, on readability is pretty limited the gain IMHO) , our use cases mostly require precise timings.
I see how easy it is to read ~2m instead of 115s, but 115s could be there because of a specific use case.
We can round up only on fixed intervals that are multiples of a bigger unit: 120s to 2m, 180m to 3h, 7 days to 1 week etc.
Everything that is not a multiple should be kept in its original (30 days is 30 days not 1 month) form even if it could look "difficult" to read.
I'm also fine having no rounding multiples at all: the user can always configure 120s or 2min they can do that by themself.
I strongly believe that the humanized version of an interval/duration should be applied to timestamps that require minimal precision like here in GitHub where I don't need to know at which second or minute a comment was posted but is just fine knowing that happened ~16 hours ago.

[JasonStoltz]

We bumped this issue up in priority. We'll plan to implement this sometime in the next few weeks.