Improve time entry form

[kevinpapst]

Describe the problem

For instance if you enter ":35" for duration it isn't smart enough to know you mean "0:35".

Describe the solution you'd like

Detect a colon : and interpret this as minutes

Describe alternatives you've considered

No response

Screenshots

No response

[sharky98]

Hello, I was looking to update my instance and saw this item. I would like to add some few pain point regarding this.

My rationale for them is: I am living in a multilingual (American English, Canadian English, French Canada) and multicultural (USA, English Canada, Quebec) region, working in a multi-national (Canada, France, UK, Germany, etc.) company. This means that end-users are kinda "polyglot" when it comes to date-time formatting as we are used to see them all mixed. At the same time, we tend to have a default way to enter them, which might not be the one that the system is configured to deal with. And like I said in a previous discussion, on a personal view, the different locales doesn't match my "ideal" date-time formatting. 😉

Here the pain points:

1. Some locales may be set to have spaces around the colon : such as "15 : 35".
   1. A time entry of "15:35" is seen as faulty.
      • Interpret "15:35" as if there was spaces around the colon :.
2. Some locales may use h as delimiter such as 15 h 35.
   1. A time entry of "15 : 35" is seen as faulty.
      • Interpret "15 : 35" as if the colon : is used in lieu of the h.
   2. A time entry of "15h35" is seen as faulty.
      • Interpret "15h35" as if there was spaces around the h.
      • Combined with item 1i above, this mean that "15:35" should also work.
3. If the format is using 12h clock, it append AM or PM (with or without spaces)
   1. Consider the use cases 1i, 2i, 2ii regardless of 12h or 24h clock.
   2. A time entry of "15:35" is seen as faulty.
      • Interpret "15:35" as being "3:35 PM".
   3. A time entry of "3:35" is seen as faulty.
      • This cannot be 100% assumed to be "3:35 AM".
      • Possible outcomes are:
        • Interpret "3:35" as being "3:35 AM".
        • Warn user, but interpret "3:35" as being "3:35 AM".
        • Add toggle user option whether they want to interpret "3:35" as being "3:35 AM" or as faulty value.
        • Keep as faulty value.
   4. A time entry of "3:35AM" is seen as faulty (with space before the AM).
      • Interpret "3:35AM" as being "3:35 AM"
   5. A time entry of "3:35 AM" is seen as faulty (without space before the AM).
      • Interpret "3:35 AM" as being "3:35AM"

[ckuetbach]

I would like to add, that the time (start and also end time) and not only the duration could be improved.

We updated from Kimai 1.x to Kimai 2.x and encountered that the time entry was a feature degradation.

With Kimai 1 I was able to enter 1645 and it was automatically formatted to 16:45. Now I would need to enter the colon.

[ckuetbach]

Exactly as I wrote my last comment, some one added this feature request: #4723

[kevinpapst]

@darioackermann If you propose a PR, make sure that currently supported formats do not break:
https://www.kimai.org/documentation/duration-format.html

This could be a starting point for the JS code:
https://github.com/kimai/kimai/blob/main/assets/js/plugins/KimaiDateUtils.js#L266

[ckuetbach]

@kevinpapst could you also reopen the other issue? Or should that be fixed together with this one?

[joho1968]

Wouldn't at least a partial fix be to remove everything that's not a digit and then re-construct the time entered according to the locale, adding colons, dashes/slashes/dots (dates) and assume either 0 or 00 where there are no numbers for time, and the current date's various components where there are no numbers for date?

[Hkllopp]

Wouldn't at least a partial fix be to remove everything that's not a digit and then re-construct the time entered according to the locale, adding colons, dashes/slashes/dots (dates) and assume either 0 or 00 where there are no numbers for time, and the current date's various components where there are no numbers for date?

I'm not sure removing any non-digit then reconstruct the time with zero-filling is a good idea because it is not clear if zeroes should be included before or after the digit.

user input : ":1"
cleaned input : "1"
reconstructed time : "10:00", "01:00", "00:10" or "00:01" ?
I think it should be "00:01" (because pre-digit colon means minutes and I think it's not logical to say 1 is 10 but abreviated)
So the colon should be kept in my opinion

Also, we need to think about the "hours speed filling" case.
I would like very much to be able to input "8" and it should be interpreted as "08:00" (AM by default if under or equals to 12, else PM or converted to 24h format)

[joho1968]

IMHO:

1 and :1 equals one minute
10 and :10 equals ten minutes
1:1 equals one hour and one minute
1:10 equals one hour and ten minutes

But perhaps there could be an option for "hours speed filling" then ... which could bring

1 equals one hour
1,25 and 1.25 equals one hour and 15 minutes
1,5 and 1.5 equals one hour and 30 minutes
1,75 and 1.75 equals one hour and 45 minutes

and so on ... 🤔

And, it could be context aware.

Duration time handling is different from end time handling.

So maybe "hours speed filling" is only used for duration, with the possibility for decimals.

Don't know what's best or right, just throwing out ideas 😊

[niels-przybilla]

For the duration entry (if you do not care about exact start/stop Times) could be like:
30m
1h
1,5h
and so on.