Running Catalog Lightcurve Time and Data Set Time Don't Match

[ycendes]

I noticed that when checking light curves like this one- http://banana.transientskp.org/master/vlo_SB003cendes/runningcatalog/5503/ the time on the lightcurve versus the first data points is off by one hour, where the light curve is one hour behind the time stamps in the data file. (I should note that even if the light curve was trying to convert to local time this would be incorrect, as we are one hour ahead of UTC.) Dit is slecht!

[gijzelaerr]

ok so when I look at this page:

http://banana.transientskp.org/master/vlo_SB003cendes/image/80314/

Filename: F5.73257e+07_S1-63_T20-11-2013_16-57-00.image
start date (UT): Nov. 20, 2013, 5:57 p.m.

I think since LOFAR/AARTFAAC is in NL it specifies the time in the filename as Central European Time. But since AARTFAAC doesn't specify a timezone TraP assumes it actually is UCT, and stores it this way. Since our banana server is in NL it assumes dutch time zone and will add one hour to the display. So the problem is in the AARTFAAC naming of files. Bouncing this to @Error323 , please reopen this issue if my analysis is wrong.

[ajstewart]

I'm getting the same issue in Australia using VLA data. The time listed by the TraP is the correct start time, the highcharts plot is behind by one hour.

[ajstewart]

Problem here was the base.py hard coded setting of TIME_ZONE = 'Europe/Amsterdam'. Hence highcharts assumes the times to be of this TZ and attempts to correct it to UTC hence it being an hour behind on the light curve plot. Same was seen when setting it to Australia/Sydney resulting in an 11 hour shift.

It's solved by changing to to UTC in base.py. This doesn't seem to have any negative effects, e.g. the processing start/end time is still stated in my local time.