Manually entering a time before 10:00:00 does not automatically add a prefixed 0 to the time in the Entries section. This results in the “Time On” column not sorting correctly. Manually entering the leading zero in the existing Entries by editing them and including it when filling in the Time field for a new (historical) contact result in the entries sorting correctly.
This is a niche paper log and late shift combination, but I’ve got that!
Any attention for this?
Can you give an example, or perhaps take a screen shot of a log?
I tried manually entering an 11:00 QSO followed by an 09:00 and then an 08:00 QSO, and the log sorted properly — with the latest time (11:00) on top.
Note that times before 1000 are entered with a leading zero.
That’s exactly the point. Even with a correctly placed colon in the time, the data entry field does not adjust the formatting and saves it as-entered while failing to correctly handle no-leading-zero.
Oh, i think I understand. You’re entering three digits instead of the usual four digits for the 24-hour (UTC) time. The time only saves with three digits, and then it doesn’t sort properly:
@jarrett was trying to fix the problem where people were entering an invalid time (such as one that wasn’t between 0000 and 2359) and added a validation feature to disallow it. You’ll also note that trying to enter a time that starts with 3 doesn’t work either, since no proper 24-hour time starts with 3. You can’t enter 2:40 am for the same reason (no valid UTC time starts with 24); enter 0240 instead.
Can’t you simply enter 4-digit times instead when you pause the time? Or are you running into problems with that too? You shouldn’t need to edit each QSO later to make this work properly.
Also note that you never need to type the colon. That is always handled for you.
Yes, I can successfully enter all four digits in the time field. However, it would be best if the leading zero wasn’t required and/or was automatically corrected in the field.
Cool—glad it does work for you when entering 4 digits upon initial entry of the QSO.
@jarrett, not sure if you plan to revisit the time entry validation, but @trm’s catch has potential to cause some user errors or at least confusion if they attempt to enter 3 digit times earlier than 1000.
My suggestion: fill the time entry from right to left (instead of left to right) as digits are entered, and shift the prior ones to the left. That way the user can stop at 3 digits and it would still validate at times less than 1000. So “245” would be validated as well within the 24-hour clock (displayed with the leading zero and colon, of course) whereas under your current method it would not be allowed.
Taking this one step further, a “45” (which is 0045) could be entered and would appear first as “:04” and then “:45” once the second digit is entered, and if the user moves onto the next field or saves the record it would be formatted as “00:45”. Stop with the “4” (a single digit) and we have “00:04”.
Formatting as users type is what added complexity to this field. I think, to ultimately be done with bugs in this field, that I’m simply going to normalize fields on save. If you type 1:45, it will be converted to 01:45, etc when it is saved. Would that solve this, @KZ3L?
I guess that depends. Can you show what you mean by this?
Perhaps using the same approach used when entering a frequency would be a good model to use. Check it or convert it when tabbing or saving instead of using live validation.
Let the user enter 1 up to 6 digits, and allow them to type a colon also if they wish. Strip the colon and compare the number to a valid time entry. 4 digits is compared to 24-hour clock with minutes, and 5 or 6 digits is compared to a 24-hour clock with seconds. An invalid time (like 25:45) would get the red-text warning underneath the field and saving would be prohibited.
Or… just keep it to four digits and your live validation wouldn’t allow any more to be entered. (Keep it to minutes only if that is simpler, as you do now.)
Examples:
1 → 00:01 when tabbing or saving
245, 0245, 2:45, and 02:45 → 02:45
2545 → “invalid time”
51 → 00:51
61 → “invalid time”
Blank entry → “invalid time”
More than 4 digits → assume the last two digits are seconds, and format accordingly. (Optional feature, but not critical)
Has this been pushed into a ticket/planned change, yet? (poking to delay the auto-lock)
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.