View Issue Details

IDProjectCategoryView StatusLast Update
0001714SkyChart1-Softwarepublic18-10-09 17:35
ReporterSasa Assigned ToPatrick Chevalley  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinux 32-bitOSLubuntuOS Version17.04
Product Version4.1 SVN 
Target Version4.2 
Summary0001714: Julian date conversion - rounding bug
DescriptionIf convert Julian date near midnight, it will switch to 0h, however day will not turn over.
Steps To ReproduceFor instance:

2299160.49999 = 1582-10-04 23:59:59
2299160.499999 = 1582-10-04 00:00:00 instead 1582-10-15 00:00:00

2457893.49999 = 2017-05-20 23:59:59
2457893.499999 = 2017-05-20 00:00:00 instead 2017-05-21 00:00:00


TagsNo tags attached.

Activities

Sasa

17-05-19 03:13

reporter   ~0003810

Last edited: 17-05-19 03:14

Of course when round correctly, JD should be changed to integer part + 0.5.

Or, if do not allow fraction of seconds, JD should be limited to 5 decimal points on input.

Patrick Chevalley

17-05-22 15:30

administrator   ~0003813

I cannot reproduce the problem.

Both my 32bit and 64bit Linux version do the following:
2299160.49999 = 1582-10-04 23:59:59
2299160.499999 = 1582-10-04 24:00:00
2299160.4999999999 = 1582-10-15 00:00:00
2457893.49999 = 2017-05-19 23:59:59
2457893.499999 = 2017-05-19 24:00:00
2457893.4999999999 = 2017-05-20 00:00:00

I agree the 24:00:00 is not very nice but not wrong, this is only a formating problem in function TimToStr().

Can you confirm two point:

- Is 2457893.49999 really show as 2017-05-20 on your system, not 2017-05-19 ?

- To be sure it is also a text formating problem (not jd conversion problem) on you system can you zoom the map on the Moon with date set to 2457893.49999, then change date to 2457893.499999 and look if the Moon jump one day back or not.


Sasa

17-05-22 17:05

reporter  

2457893.4999.png (243,067 bytes)   
2457893.4999.png (243,067 bytes)   

Sasa

17-05-22 17:05

reporter  

2457893.49999.png (243,771 bytes)   
2457893.49999.png (243,771 bytes)   

Sasa

17-05-22 17:06

reporter  

2457893.5.png (251,073 bytes)   
2457893.5.png (251,073 bytes)   

Sasa

17-05-22 17:26

reporter   ~0003814

Last edited: 17-05-22 17:32

To be more clear, this is tested with latest .deb version SVN 3586

Attached screenshots for:
2457893.49999
2457893.499999
2457893.5

The Moon apparently does not move position on any of these values.

I do not mind 24:00:00 value in label, however, comparing date and time on label, edit fields and the chart show the problem exists. It doesn't matter it is pressed Enter, Apply or save config on exit and reopening. When reopening, TrackEpoch in .ini file is exactly entered in JD edit field.


It is highly unlikely anyone will ever enter such JD, however for such border values it show wrong date and time, even calculation seems to be proper regarding entered JD.

Sasa

17-05-23 06:45

reporter   ~0003815

Last edited: 17-05-23 06:58

Furthermore. Entering 2457893.499999 and entering 1 second (or click on UpDown) will change JD value to 2457892.500012 (!!! one day off), then back to zero will keep 2457892.500000 (still one day off).

Doing the same with Day edit field will simply add or subtract current JD value, leaving fractions the same and JD consistent.

This as well demonstrate Julian date conversion bug due unhandled fraction values and rounding.

I had similar problem working on artificial satellite orbit prediction and to obtain maximum precision I kept whole 11 decimal points for JD and to keep datetime displayed as close possible with 3 decimal points for seconds, avoiding rounding when display.

Patrick Chevalley

18-10-09 17:35

administrator   ~0004935

This is fixed by truncating the JD input to five decimal place. This is less than one second so it make no sens to want more digits here.

https://github.com/pchev/skychart/commit/88aa8b8bafda11a1a94ddc962914c464d1bdf7b2

Issue History

Date Modified Username Field Change
17-05-19 02:58 Sasa New Issue
17-05-19 03:13 Sasa Note Added: 0003810
17-05-19 03:14 Sasa Note Edited: 0003810
17-05-22 15:30 Patrick Chevalley Assigned To => Patrick Chevalley
17-05-22 15:30 Patrick Chevalley Status new => feedback
17-05-22 15:30 Patrick Chevalley Note Added: 0003813
17-05-22 17:05 Sasa File Added: 2457893.4999.png
17-05-22 17:05 Sasa File Added: 2457893.49999.png
17-05-22 17:06 Sasa File Added: 2457893.5.png
17-05-22 17:26 Sasa Note Added: 0003814
17-05-22 17:26 Sasa Status feedback => assigned
17-05-22 17:28 Sasa Note Edited: 0003814
17-05-22 17:32 Sasa Note Edited: 0003814
17-05-23 06:45 Sasa Note Added: 0003815
17-05-23 06:46 Sasa Note Edited: 0003815
17-05-23 06:46 Sasa Note Edited: 0003815
17-05-23 06:47 Sasa Note Edited: 0003815
17-05-23 06:51 Sasa Note Edited: 0003815
17-05-23 06:58 Sasa Note Edited: 0003815
18-10-09 17:35 Patrick Chevalley Status assigned => resolved
18-10-09 17:35 Patrick Chevalley Resolution open => fixed
18-10-09 17:35 Patrick Chevalley Target Version => 4.2
18-10-09 17:35 Patrick Chevalley Note Added: 0004935