View Issue Details

IDProjectCategoryView StatusLast Update
0003090Ham Radio DeluxeBugpublic2019-02-24 15:12
ReporterWA9PIEAssigned ToK7ZCZ 
Status closedResolutionfixed 
Product Version6.5.0.187 
Target VersionFixed in Version6.5.0.196 
Summary0003090: Time shown below each of the passes in the "Next Passes" pane are off by 60 minutes late
DescriptionThe "Last Passes" pane shows a time graph for the next few passes for a given satellite.

Above each of these time charts is a time, which is the AOS (Acquisition of Signal) time. This time is correct.

Below each of these time charts are times in 5 or 10 minute increments. They are wrong by 60 minutes.

The far left hand side of the graph should be the time of AOS. It should match the time above the time graph. Each of the time gradients below the chart should be based on the AOS time. The far end of the time graph is the LOS (Loss of Signal); though it's not otherwise displayed in the Next Passes dialog box.

I'm suspicious that this could be the cause of Mantis 1564. So I'm related it here.
Steps To ReproduceLaunch the Satellite Tracking app...
Pick any satellite (a few examples might be ISS, SO-50, AO-91, AO-92, AO-51)
Display the "Next Passes" pane
Observe that there is a 60 minute difference between the time above the time graph and the times below the time graph.
TagsNo tags attached.
ModuleSatellite Tracking
Testing Beta Successful


related to 0001564 closedWA9PIE Line in "Next Passes" no longer follows the satellite across the horizon 
related to 0003140 closedK7ZCZ SystemTimeTotimet() copy-paste function is broken 



2019-01-24 01:21


NextPassesCharts.png (36,863 bytes)
NextPassesCharts.png (36,863 bytes)


2019-01-26 06:11

developer   ~0007079

This doesn't repro for me. I've what I see as a result, and here are the steps I'm following:

1) Start up Satellite Tracker
2) In the "Satellite Definitions" tab, use the "Enable None" button in the tab's toolbar to clear all the definitions
3) Mark the "Enable" box for the ISS
4) Press the "Next Passes" button in the main toolbar

Result) I get the attached view. The title's time seems to match the left-most appearance of the tracked body.

Here is what I notice:

1) The report says "The "Last Passes" pane shows a time graph", but I can't find a "Last passes" window in the product. How do I bring it up?

2) The given instructions seem to contradict the report. The report says "Last passes", but the steps say "Next Passes". The screen shot also says "Next passes", as does the title of the issue.

3) The UI in the provided screen shot doesn't include the name of the satellite in the bold text above the graph. In my window, the name of the satellite is in the title of the graph. Why is that?

4) The UI have is quite different. I've got a tab in a main window. Looks like the "Next passes" window shown here is dockable, but I can't make that happen in the UI that I have. How do I set up and navigate the app to show this same as attached in the report?

I'm not particularly familiar with this application. I've fixed a couple of bugs in it, but that's it. As such, I have to ask for clear, correct, explicit repro steps.

I know the app has tons of settings. For example, isn't the AOS time calculated based on my location? To reproduce this issue, what location should I use? I also see that there are settings for using UTC or Local time. Which setting is in use for this issue? Why my display so much different than the one shown in this issue?

PassesIIS.png (81,269 bytes)
PassesIIS.png (81,269 bytes)


2019-01-30 00:45

administrator   ~0007151

Last edited: 2019-01-30 00:56

View 3 revisions

I followed your steps and was able to again recreate the problem I reported originally. There must be some setting at fault here.

We have had many report this problem. We now just have to figure out what setting is causing this.

Try repeating your steps using UTC (selected in Options > Formats > Time > UTC (GMT)

FWIW - you and I are equally familiar with this application. I'll get the documentation updated as we fix it.


2019-01-30 10:42

developer   ~0007159

Last edited: 2019-01-30 10:43

View 2 revisions

I have tried both UTC and local time, no difference.

The product has hundreds of settings; almost any one can (sometimes surprisingly, unintuitively) be involved in demonstrating a particular issue. I think that situation is particularly true for Satellite Tracker, since it relies on the user's location and the current time plot satellite locations.

I'm worried that something fundamental is different here, though. Why does your screenshot look so different than the one I have? Because of such a fundamental difference, I have to wonder if we're even looking at the same application.


2019-01-30 12:24

administrator   ~0007161

Mike C has asked me to try to replicate this issue, which I am able to. The steps I took to rep it follows:

1. Run HRD and open Satellite Tracker
2. Select the ISS to track
3. Click on "Options" icon and select the "Formats" tab. Select "Local" time in the Formats tab and close the Options.
4. Click on "Next Pass" to display the graphics for the next passes of the ISS
5. The AOS indicated at the top of the graphic and the AOS indicated by the timeline at the bottom of the graphic match at 15:59 local time at my QTH today.
6. Again, select "Options > Formats >" and select "UTC" time in the Formats tab, then close the Options.
7. Select "Next Pass" for the ISS
8. Looking at the AOS at the top of the UTC image shows 20:59 UTC time, which is correct since my timezone is UTC-5 or 20:59 - 5 = 15:59 Local time.
9. Observe the timeline at the bottom of the same UTC image and you will see that it indicates an AOS of +1 hour difference that the AOS indicated on the top of the image.

There appears to be a difference in calculating the timeline on the bottom of the UTC image compared to the calculation of the timeline on the bottom of the Local image.

To make certain the difference was clearly indicated, the attached images are EXACTLY the same image from the Next Pass group. The only difference was the selection of the Local and UTC times in the Options > Formats screen.

Local Time.jpg (22,428 bytes)
Local Time.jpg (22,428 bytes)


2019-01-30 13:33

administrator   ~0007164

Adding some extra notes here regarding observations:

- if I change the time on my computer to UTC, then go and flip the time option in SatTrack between local and UTC, (a) they are both the same, as expected and (b) they are both correct
- thinking that maybe K7ZCZ has a machine set to "(UTC-0800) Pacific Time (US & Canada)", I changed the computer to that time zone; the case still repros
- thinking that maybe there's a problem calculating to the non-UTC time zones available in the OS (as demonstrated by the last bullet), I changed the time zone on the computer to "(UTC-0800) Coordinated Universal Time-08". At this point, the behavior in SatTrack is accurate when using "Local" or "UTC"

Overall, this seems to indicate that there's a problem with calculating between UTC and local time zones.


2019-01-30 19:31

developer   ~0007171

The instructions provided by KB3NPH don't match what I see. Step 3 says to use the "Options" icon to reach the program's settings, but I don't have an Options icon displayed after finishing Step 2.

To continue with those instructions, I proceed by using the "Options" command in the "Tools" menu to set Local time. From there, I get to step #9 where I end up with a next passes view that has times in the graph caption that match the minimum of the elevation graph's X-axis.

Above, I asked why the UI that I see was so much different than the UI shown in the first screen shot provided in this issue. It turns out that I was reaching the elevation graphs in the next passes view, while the issue is reporting a problem with the "Next Passes" pane. However, KB3NPH provides instructions that lead to the next passes view, which is different code in a different window. Can we conclusively say if this issue appears only in the next passes pane or only in the next passes view? Or does the issue show in both windows?

When I first discovered the Next Passes pane, I was able to briefly reproduce the issue on a VM I use for testing. I assumed the issue was that the problem appears only in the next passes pane, not the view. Since then, I haven't been able to reproduce the issue in either window on any machine.

The information provided by KB3NPH provides something we didn't know before, which is that the erroneous time are displayed when the the application's options are set to show UTC. Is that always the case? If so, then we have a challenging issue: the times shown on the graph are displayed by a graphing library that we distribute with the product. I have zero documentation for this library; I don't have the source code, and I don't know of any support or licensing for the library. I'm not sure how the library ends up formatting or calculating time-domain information.


2019-01-30 19:40


AfterStep9.png (110,222 bytes)
AfterStep9.png (110,222 bytes)
AfterStep2.png (120,521 bytes)
AfterStep2.png (120,521 bytes)


2019-01-30 20:44

developer   ~0007172

Might be caused by 3140


2019-01-30 20:57

administrator   ~0007173

I'm attaching a sheet where I tested every single time zone in Windows 10 along with the DST setting.

What it shows is that this case will repro any time the "Adjust for daylight savings time automatically" box is checked. This clearly ties this to DST.

That said, it could be 3140... if 3140 screws up DST. For all I know, the SatTrack program is the only one with visual evidence resulting from the DST problem (3140).

AllTimeZones.xlsx (14,090 bytes)


2019-01-30 22:53

developer   ~0007175

There are two issues related to 3140, both with a chance of showing evidence from the problem that 3140 describes.


2019-01-31 19:41

administrator   ~0007185

Last edited: 2019-01-31 19:58

View 2 revisions

189 build:
I just used Microsoft Problem Steps Recorder (PSR) to record steps with images that reproduce this issue. I'll continue collecting more information.

Replication Steps for Mantis 3090.docx (4,074,501 bytes)


2019-01-31 20:01

administrator   ~0007186

With the 189 build, I have found the problem (but not the cause).

Regardless of the time format selected in SatTrack, the time above the graph correctly shows the time of the pass in the selected time format. This is good - this part is working normally.

Problem is - regardless of the time format selected in SatTrack, the time below the graph will ALWAYS show local time in 24 hr format. This is wrong. It should show time in the same format as selected in the time format option.

Image attached.

SatTrack Time Zone Problem (3090) 01.png (1,414,568 bytes)


2019-01-31 23:07

administrator   ~0007188

3140 seems to have resolved problems with DST. Now the problem is 3090 is clearer... where the graph is always showing local time in 24 hr format when it should follow what's been selected in time format (as it does above the graph).

When 3090 is fixed, then 1564 will go away.


2019-01-31 23:59

developer   ~0007190

Something must be very wrong. I downloaded "Replication Steps for Mantis 3090" and tried to follow it.

I didn't get far.

The first page says the user clicks on "Satellite tracking". No notes explain any context, but from the UI I gather that Step 1 starts at running the Logbook appication.

The next page (not the next step) says "set the time in HRD Satellite Tracking ..." but that's not the UI see after the first step. Not even close.

How do we reconcile what I actually see from the steps I'm given to reproduce this issue?


2019-02-01 12:27

administrator   ~0007199

Attempt #next in replication steps using PSR.

Let me know if there are remaining questions.

3090 Repro Steps v316.docx (1,780,947 bytes)


2019-02-01 14:32

developer   ~0007201

I found a spot where the UTC-to-local bias was being mis-used as number of minutes rather than a number of seconds. I'd expect that to cause an off-hour difference, but these reports say that local time is kept or that the time is six hours away.

For me in UTC-8 right now, the math should subtract 8 * 60 * 60 == 28800 seconds. Instead, it is adjusting 8 * 60 == 480 seconds, which is 8 minutes. Certainly, a difference of 8 minutes is closer to local time than 8 hours, but it's also not exactly the local time symptom that's being reported.

For reports coming from the UTC-6 time zone, I'd expect the time to be 6 minutes away (or, five hours, fifty-four minutes away), not exactly local time (exactly 0 minutes off, or exactly 6 hours off).

I've made a fix for the minutes conversion because I can see that it's incorrect. But I can't offer any explanation for the reported symptoms. for now, let me know if the minutes/seconds fix helps. If it's fixed, great; if not, I think we need to find a more productive way to approach this problem.

This checkin has the minutes/second fix:


2019-02-01 18:11

developer   ~0007207

The most recent change should be visible in the 190 build


2019-02-01 20:01

administrator   ~0007214

Validated... awesome!

Issue History

Date Modified Username Field Change
2019-01-24 01:21 WA9PIE New Issue
2019-01-24 01:21 WA9PIE File Added: NextPassesCharts.png
2019-01-24 01:21 WA9PIE Relationship added related to 0001564
2019-01-24 01:22 WA9PIE Assigned To => K7ZCZ
2019-01-24 01:22 WA9PIE Status new => assigned
2019-01-26 06:11 K7ZCZ File Added: PassesIIS.png
2019-01-26 06:11 K7ZCZ Note Added: 0007079
2019-01-26 06:11 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-01-26 06:11 K7ZCZ Status assigned => feedback
2019-01-30 00:45 WA9PIE Note Added: 0007151
2019-01-30 00:49 WA9PIE Note Edited: 0007151 View Revisions
2019-01-30 00:49 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-01-30 00:56 WA9PIE Note Edited: 0007151 View Revisions
2019-01-30 10:42 K7ZCZ Note Added: 0007159
2019-01-30 10:43 K7ZCZ Note Edited: 0007159 View Revisions
2019-01-30 12:24 KB3NPH File Added: Local Time.jpg
2019-01-30 12:24 KB3NPH File Added: UTC Time Showing 1 hour difference.jpg
2019-01-30 12:24 KB3NPH Note Added: 0007161
2019-01-30 13:33 WA9PIE Note Added: 0007164
2019-01-30 13:33 WA9PIE Status feedback => assigned
2019-01-30 19:31 K7ZCZ Note Added: 0007171
2019-01-30 19:40 K7ZCZ File Added: AfterStep9.png
2019-01-30 19:40 K7ZCZ File Added: AfterStep2.png
2019-01-30 20:44 K7ZCZ Note Added: 0007172
2019-01-30 20:44 K7ZCZ Relationship added related to 0003140
2019-01-30 20:57 WA9PIE File Added: AllTimeZones.xlsx
2019-01-30 20:57 WA9PIE Note Added: 0007173
2019-01-30 22:53 K7ZCZ Note Added: 0007175
2019-01-31 19:41 WA9PIE File Added: Replication Steps for Mantis 3090.docx
2019-01-31 19:41 WA9PIE Note Added: 0007185
2019-01-31 19:58 WA9PIE Note Edited: 0007185 View Revisions
2019-01-31 20:01 WA9PIE File Added: SatTrack Time Zone Problem (3090) 01.png
2019-01-31 20:01 WA9PIE Note Added: 0007186
2019-01-31 23:07 WA9PIE Note Added: 0007188
2019-01-31 23:59 K7ZCZ Note Added: 0007190
2019-02-01 12:27 WA9PIE File Added: 3090 Repro Steps v316.docx
2019-02-01 12:27 WA9PIE Note Added: 0007199
2019-02-01 14:32 K7ZCZ Note Added: 0007201
2019-02-01 18:11 K7ZCZ Note Added: 0007207
2019-02-01 20:01 WA9PIE Status assigned => closed
2019-02-01 20:01 WA9PIE Resolution open => fixed
2019-02-01 20:01 WA9PIE Fixed in Version =>
2019-02-01 20:01 WA9PIE Description Updated View Revisions
2019-02-01 20:01 WA9PIE Steps to Reproduce Updated View Revisions
2019-02-01 20:01 WA9PIE Testing Not Started => Beta Successful
2019-02-01 20:01 WA9PIE Note Added: 0007214
2019-02-02 12:35 K7ZCZ Status closed => resolved
2019-02-02 21:37 WA9PIE Status resolved => closed
2019-02-24 14:40 WA9PIE Fixed in Version =>
2019-02-24 15:12 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe