View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002798||2 - Next Dev List (Holding Area)||Bug||public||2018-07-02 03:42||2020-07-02 02:22|
|Platform||PC||OS||Windows||OS Version||10 64 bit Home|
|Summary||0002798: The Date field in ALE can reverse DD/MM to MM/DD|
|Description||Using the Next/Prev buttons in the ALE window with a QSO open the Date field can revers the DD/MM to MM/YY|
The day has to be less than 12 for this to happen.
|Steps To Reproduce||Open the Logbook ALE with a QSO with a Day date of 12 or more making sure that the Prev date is also 12 or more.|
Press the Next button and the DD/MM stay as they were.
Now select a Day of 12 or less and repeat. The DD/MM swap.
My Windows 10 Date setting is DD/MM/YYYY.
|Additional Information||This has been reported in the Peer Forum.|
One customer contacted support and was told -
"This changing is strange. I checked with our programmers and they confirmed that the date format is 100% controlled by
the date format set in the Windows software. It would appear if the format was changing, it would have to be something in Windows that is causing the change and not something in HRD."
|Tags||No tags attached.|
The forum thread in question is here: https://forums.hamradiodeluxe.com/node/46870
The ticket in question is here: https://support.hamradiodeluxe.com/scp/tickets.php?id=7867
It's simply false that "the date format is 100% controlled by the date format set in the Windows software." The logbook uses two different fixed formats itself internally, and converts between those two formats. It converts from those formats to the displayed format. The displayed format should be set by the user's preference in Windows, but it sometimes isn't. The conversion of formats is sometimes incorrect, and bugs like this are the result.
The conversions are not factored correctly. They're copied and pasted throughout the code, and certain bugs exist in certain places; but are fixed in others. Undoubtedly, there are compensating bugs in different places and false dependencies grown from that situation.
We can probably figure out exactly whre this specific format conversion is confused, but the correct ifx would be to get the logbook's code to internally use exactly one date/time representation. Then, convert to and from user formats in exactly one place.
||Updating these to Feedback, as all have questions or need re-tested.|
||No change was made to the code; there's nothing to test here. My notes above indicate that I evaluated the code and they suggest a solution. The solution hasn't yet been implemented.|
||Not yet fixed.|
||No change in behaviour is expected, as no change to the code has been made. Is a more reliable repro case available?|
|2018-07-02 03:42||g3ucq||New Issue|
|2018-07-03 19:45||K7ZCZ||Note Added: 0005604|
|2018-07-25 12:53||WA9PIE||Status||new => feedback|
|2018-07-25 12:53||WA9PIE||Note Added: 0005785|
|2018-07-25 14:01||g3ucq||Note Added: 0005822|
|2018-07-25 14:01||g3ucq||Status||feedback => new|
|2018-07-25 22:50||K7ZCZ||Note Added: 0005829|
|2018-09-02 23:50||K7ZCZ||Relationship added||related to 0002872|
|2018-12-21 14:52||WA9PIE||Project||Issues Needing Retest => 3 - Current Dev List|
|2019-03-07 04:45||g3ucq||Note Added: 0007619|
|2019-03-07 08:39||K7ZCZ||Note Added: 0007626|
|2020-07-02 02:22||WA9PIE||Project||3 - Current Dev List => 2 - Next Dev List (Holding Area)|