Can you please clarify if the local time and time zone are set correctly in your computer?
I have a vague recollection of this question being asked on the forum before and, if I recall correctly, the camera stored the time (in its firmware I guess) and it was set incorrectly.
Of course, my memory could be playing tricks . . . perhaps try searching the forum.
No answer for this topic since 1 year? I discovered this bug last week with my observatory. My version is 3.0.2.82.
I’ve made a couple of test and it’s a real SGP bug.
The documentation says :
DATE-LOC: Local observation date (time image was written to disk)
DATE-OBS: UTC observation date
SGP read the timezone at start. SGP writes the header when an image is saved. DATE-LOC is the time image was written to the disk, then SGP add timezone to calculate DATE-OBS.
The bug is for DATE-LOC. SGP think time image written to disk is UTC and remove the timezone. Then SGP apply the timezone to calculate DATE-OBS.
At the end DATE-LOC is wrong and has nothing to do with anything and DATE-OBS is local time.
So let’s imagine you’re in Chile like me wich is UTC-4 timezone.
Real local time or saved fits time on hard disk : 7:00
DAT-LOC = Real local time - timezone (this is the bug) so DAT-LOC = 7 - 4 = 3:00
DAT-OBS = DAT-LOC + timezone (formula is ok) so DAT-OBS = 3 + 4 = 7:00
I changeg timezone, localtime, daylight saving and I can always reproduce the bug on my Windows 10 machine.
I hope this will help and will be corrected soon because it can be really confused when you want to use time to confirm exoplanet or retrieve orbital parameters of a solar system object.
I have images taken with v2.6.0.23, but the times seem to be correct in the headers. The images were taken in the winter in UTC+2 timezone, and one image shows 21:00 for DATE-LOC and 19:00 for DATE-OBS, which are both correct.
I only recently updated to v3.x, so I don’t have images taken with that version yet.
Either this is a regression in a newer version or it’s happening only with specific timezones or settings.
You’re absolutely right, this is weird. And because the source-code is not open, we don’t know how SGP works. And because it affects a lot of user for a long time, administrators should take a look.
The only thing I know is that SGP writes the header when it saves the file. For example, if you take a quick frame with the frame and focus docking module, SGP will tell you there is no header with the frame. You have to save it and reopen it to view the header.
I can’t make more test for a while, it’s rainy in Chile and we have to save the power…
Hi, I have also this problem how SGP handles UTC and local time conversions in image file data field DATE-LOC.
Here is one SGP log example of one image download:
[09.13.18 00.27.19.962][DEBUG] [Sequence Thread] Collecting FITs headers… [09.13.18 00.27.19.969][DEBUG] [Sequence Thread] QSI Camera - Camera reports last image start time as: 2018-09-12T21:26:35.850 UTC
[09.13.18 00.27.19.969][DEBUG] [Sequence Thread] DATE-LOC time provided by camera…
[09.13.18 00.27.19.973][DEBUG] [Sequence Thread] GatherFitsHeaders: Writing header info from UI…
[09.13.18 00.27.19.977][DEBUG] [Sequence Thread] Clearing timed monitoring events…
[09.13.18 00.27.19.984][DEBUG] [Sequence Thread] Created full file name (file does not exist): D:\Astro\QSI\2018-09-13\Light\Alpheratz_30sec_1x1_G_frame1.fit
Timedates in brackets are actual local times (EEST=UTC+3).
And here is the information in FITS-file header after SGP has generated and saved it:
OBJECT = ‘Alpheratz’ / Object name DATE-LOC= ‘2018-09-12T21:26:35’ / Local observation date DATE-OBS= ‘2018-09-12T18:26:35’ / UTC observation date
IMAGETYP= 'LIGHT ’ / Type of frame
CREATOR = ‘Sequence Generator Pro v3.0.2.94’ / Capture software
My camera QSI690 define the unit of image DATE-LOC timestamp as UTC, but SGP uses this UTC timestamp as local time. Then SGP convert this already UTC timestamp again to UTC in field DATE-OBS which is error.
Is this bug in SGP how it take into account the UTC unit information in the “Camera image start time”/DATE-LOC data field ?
Or is this bug in QSI690 because it is using DATE-LOC timedate field as UTC, although defining it’s unit is UTC ?