Skip to main content

VStar JD to HJD Conversion

8 posts / 0 new
Last post
clkotnik
clkotnik's picture
VStar JD to HJD Conversion

During testing of the upcoming VStar release, we realized that there is a difference of a second or two between the results of VStar's JD to HJD conversion and other algorithms available.  While the VStar algorithm can certainly be updated, we wonder if that is the best use of development time.

What do people think?  Are the dates in the dataset you work with in VStar accurate to subsecond?

thanks for any feedback,

Cliff

MZK
MZK's picture
Systematic Error??

Hi Cliff:

1. Take my comment with a grain of salt!  I rarely use VStar for JD to HJD conversion.

2. IF VStar gives an HJD that is off by 2 seconds from "other" algorithms (which agree with each other?), then I think you should find out why and fix. IMHO, two seconds is quite large for precise TOM assessments over years?

3. Consider asking an expert like Joe Patterson, who looks for small shifts in his CVs?

Ken

clkotnik
clkotnik's picture
Close This Out

Ken,

Thanks for taking the time to comment.  It is not really a matter of fixing the software as it is making it incorporate more sources of variation.  Before undertaking that work, we wanted to gauge the level of interest.

I'm going to conclude from the level of response that, among VStar users, sub-second time is not widely a concern.

best regards,

Cliff

TRE
TRE's picture
subsecond timing

I use Dimension 4. it reports it is good to about 400 milliseconds. But then a fit needs to be made to datasets to obtain a period. IMHO, the fits to my data don't have one second accuracy. On scraggly datasets I might not miss an hour.

Ray

TRE
TRE's picture
subsecond timing

I use Dimension 4. it reports it is good to about 400 milliseconds. But then a fit needs to be made to datasets to obtain a period. IMHO, the fits to my data don't have one second accuracy. On scraggly datasets I might not miss an hour.

Ray

arx
arx's picture
VStar JD to HJD Conversion

I never use VStar for the specific purpose of convering JD to HJD data.

If HJD light curve plots in VStar are out by about 2 seconds, that would not be a problem for me, personally.

That said, if a routine I used for heliocentric conversion was found to be out by 2 seconds, I would look for a more accurate one.

Roy

BGW
BGW's picture
Conversion

I do EB eclipse timing...  The reported uncertainty of the times of minima are very rarely smaller than 0.0001 day, i.e. 8.6 seconds.  And, those are debatable:  O-C diagrams suggest the true uncertainty is often quite a bit greater.

I suggest that if someone needs accuracies better than a few seconds, for starters they should probably be using BJD, not HJD, and it may be that they should not be referenced to UTC (as Dimension4 does).  It is a complex topic, and one I am not expert in, especially for cases where UTC is not appropriate.

I use astropy for conversions from UTC to HJD and BJD.

Gary Billings

Eric Dose
Eric Dose's picture
UTC

I'm not sure there is a problem with UTC per se.

Astropy has been mentioned, and there is a problem with python and its usual UTC implementation: python's core datetime package limits the seconds per minute to 60. This means that python's datetime can garble the leap seconds that otherwise keep UTC and certain other timescales in sync.

Astropy is much smarter about this. And recently I've discovered Brandon Rhodes' easier-to-use skyfield python package that can also do the UTC-to-other conversions carefully, using up-to-date earth-rotation and leap-second corrections (downloaded automatically).

Log in to post comments
AAVSO 49 Bay State Rd. Cambridge, MA 02138 aavso@aavso.org 617-354-0484