View Issue Details

IDProjectCategoryView StatusLast Update
00027983 - Current Dev ListBugpublic2019-03-07 08:39
Reporterg3ucqAssigned To 
PriorityhighSeveritymajorReproducibilityalways
Status newResolutionopen 
PlatformPCOSWindowsOS Version10 64 bit Home
Product Version 
Target VersionFixed in Version 
Summary0002798: The Date field in ALE can reverse DD/MM to MM/DD
DescriptionUsing 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 ReproduceOpen 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 InformationThis 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."
TagsNo tags attached.
ModuleLogbook
Sub-ModuleALE Window
TestingNot Started

Relationships

related to 0002872 closedK7ZCZ Ham Radio Deluxe QSO Forwarding Packets Sent by Logbook Have Invalid QSO Date 

Activities

K7ZCZ

2018-07-03 19:45

administrator   ~0005604

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.

WA9PIE

2018-07-25 12:53

administrator   ~0005785

Updating these to Feedback, as all have questions or need re-tested.

g3ucq

2018-07-25 14:01

updater   ~0005822

No change

K7ZCZ

2018-07-25 22:50

administrator   ~0005829

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.

g3ucq

2019-03-07 04:45

updater   ~0007619

Not yet fixed.

K7ZCZ

2019-03-07 08:39

administrator   ~0007626

No change in behaviour is expected, as no change to the code has been made. Is a more reliable repro case available?

Issue History

Date Modified Username Field Change
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