UTC showing as local time, how to fix?


#1

The UTC time is showing as actual local time, and local time is showing as the actual local time -4 hours (EDT conversion).

Example from FITS header:

DATE-LOC= ‘2017-08-20T17:54:29’ / Local observation date
DATE-OBS= ‘2017-08-20T21:54:29’ / UTC observation date

The actual local time in this example is 2017-08-20T21:54:29

The UTC should read 2017-08-21T01:54:29

It’s driving me crazy.

How do I correct this?


#2

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.

Can any one else recall a similar issue?


#3

Hello,

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.

  1. Real local time or saved fits time on hard disk : 7:00
  2. DAT-LOC = Real local time - timezone (this is the bug) so DAT-LOC = 7 - 4 = 3:00
  3. 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.


#4

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.


#5

Or could this be related to ASCOM’s LastExposureStartTime property with some cameras? Like in these threads:



#6

Sebastien, this is what I get on my side which is different from what you have :

(I removed minutes and sec, left only whole hours)

PC: Windows 10, updated to the latest update

SGP v3.0.2.91

Location: Santiago, Chile (SGP Lat and Long info verified, 33 South, 70 West)

PC time: 23h

PC Time zone: -4 (verified)

Real local time: 23h

Fits header shows:

DATE-LOC: 03 (Which is PC TIME PLUS TIME ZONE, i.e. UTC time instead of Local Time). This is different from what you got but it is still wrong.

DATE-OBS: 07 (Or DATE-LOC + Time Zone twice)

Really confusing!

Renan


#7

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…


#8

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 ?

Cheers,
Jorma


www.mainsequencesoftware.com