Leap seconds

[shbhuk]

Hi, This seems to be a great tool. Could you please indicate the precision levels it is good for. Nearest second, millisecond or better.

I ask because I do not see a leap second inclusion (might have missed it), and am wondering how that is accounted for.

Shubham

[jmccormac01]

Hi Shubham, Thanks for your comment. There are some assumptions here. The conversion should be accurate to ms, but they assume that the timestamps being converted are correct. The code is based on time conversions as calculated by astropy. You can see all the details here.

There is no leap second conversion as that should be accounted for by the computer generating the timestamps. All input timescales are expected in UTC, which has leap seconds accounted for already.

Cheers, James

[dsteeghs]

James,

The input UTC must indeed be assumed to be correct and requires the computer that produced the time stamps to be in sync, but any conversion to a non-UTC time system such as BJD then requires that the code is also aware of the relevant leap-second offset. Astropy expects that the files containing these are downloaded regularly to ensure they are up to date. This is done via IERS (http://docs.astropy.org/en/stable/utils/iers.html#utils-iers).

So its important to configure this correctly.

Danny

[trmrsh]

astropy downloads these files automatically doesn't it?

tom

On 8 June 2018 at 12:17, dsteeghs notifications@github.com wrote:

James,

The input UTC must indeed be assumed to be correct and requires the computer that produced the time stamps to be in sync, but any conversion to a non-UTC time system such as BJD then requires that the code is also aware of the relevant leap-second offset. Astropy expects that the files containing these are downloaded regularly to ensure they are up to date. This is done via IERS (http://docs.astropy.org/en/ stable/utils/iers.html#utils-iers).

So its important to configure this correctly.

Danny

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/WarwickAstro/time-conversions/issues/1#issuecomment-395730783, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8DWDNv99bbcSY5k8YUpRQzisi9e3WEks5t6l07gaJpZM4Uf4_E .

[jmccormac01]

Hi Danny, Ah, yes I see. The docs say astropy takes care of this automatically. So it should be fine.

Cheers James

For the UT1 to UTC offset, one has to interpolate the observed values provided by the International
 Earth Rotation and Reference Systems (IERS) Service. Astropy will automatically download and use 
values from the IERS which cover times spanning from 1973-Jan-01 through one year into the future.
 In addition the astropy package is bundled with a data table of values provided in Bulletin B, which 
cover the period from 1962 to shortly before an astropy release.

[dsteeghs]

Yes, it should check if it has a current file on disk, or if user forces their own source. It will download files if current copy is outdated.

We actually had GOTO crashing since the official files on the USNO server were garbled, astropy decided it wanted to download a more current file and overwrote the disk version with the garbled version. After that, all hell broke loose!

I just wanted to highlight that one always needs a current leap-second log whenever doing any time correction. By default astropy should be OK.

[jmccormac01]

Oh no, that sounds horrible. I wonder if can I force it to check before it runs each time, just to be sure. I'll take a look.

[dsteeghs]

Yeah, so I am not entirely happy with the astropy implementation.... It is unlikely, but it just happened during the night so we need to revisit this issue.

[jmccormac01]

It seems like it auto updates through one of several ways. Either, when you request a time conversion for an epoch not covered by the cached table, or every 7 days automatically.

The default IERS data used automatically is updated by the service every 7 days and 
includes transforms dating back to 1973-01-01.

The actual file from usno only updates every 7 days, so the defaults in astropy should be mostly fine. I could drop the max_age to 10 days, like they suggest.

The IERS Service provides the default online table (http://maia.usno.navy.mil/ser7/finals2000A.all) 
and updates the content once each 7 days. The default value of auto_max_age is 30 days to 
avoid unnecessary network access, but one can reduce this to as low as 10 days.

[jmccormac01]

I can see how this is an issue when running in real time though!

[trmrsh]

you only really need to update it immediately after June 30 or Dec 31; there are the only times leap seconds are added.

tom

On 8 June 2018 at 12:32, James McCormac notifications@github.com wrote:

It seems like it auto updates through one of several ways. Either, when you request a time conversion for an epoch not covered by the cached table, or every 7 days automatically.

The default IERS data used automatically is updated by the service every 7 days and includes transforms dating back to 1973-01-01.

The actual file from usno only updates every 7 days, so the defaults in astropy should be mostly fine. I could drop the max_age to 10 days, like they suggest.

The IERS Service provides the default online table (http://maia.usno.navy.mil/ser7/finals2000A.all) and updates the content once each 7 days. The default value of auto_max_age is 30 days to avoid unnecessary network access, but one can reduce this to as low as 10 days.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/WarwickAstro/time-conversions/issues/1#issuecomment-395733814, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8DWLzRRwFIrpPnVIQuTAtsdkiOyYxCks5t6mDVgaJpZM4Uf4_E .

[dsteeghs]

In our case, it checked when the first call to the time module was made during start of the night, flagged it as out of date and downloaded the bad file.

We will likely manually download and check the validity to ensure this is done during the day and not live.

Its probably very rare that USNO messes up, but it did. It was fixed several hours later, so we just tripped the update during the bad window. But I think it changes much more often than the 7 days mentioned (and contains a lot more than leap-seconds).

Thought I would share this experience as a warning....

[pchote]

Can schedule a cronjob to run during the afternoon to make sure that won't happen live.

[jmccormac01]

It's definately good to know, thanks @dsteeghs

[shbhuk]

Hi, Yes astropy can only update for a leap second if the user updates the astropy package. This is because Astropy has it hard coded.

See - https://github.com/liberfa/erfa/issues/43

Therefore we decided to implement our version of the BJD_TDB converter and barycentric velocity converter which always checks for leap seconds and updates if required. This is because we need codes running at remote observatories which might not always update in time and a 1 second error in time could be 3 cm/s for barycentric correction.

See - https://github.com/shbhuk/barycorrpy/wiki/5.-Leap-Second-Management

Were wondering if you had something similar.

[trmrsh]

Yes astropy can only update for a leap second if the user updates the astropy package. This is because Astropy has it hard coded.

I don't think this is true is it? I speak from having used these routines several times and seen them downloading the leap seconds.

Also a quote from the thread you linked to indicates this:

"Within astropy itself, we have access to updated leap seconds via IERS-A; that has the advantage of not being OS-dependent. So, at least adding the warning should be easy (PR welcome; I won't have time in the near future)."

tom

See - liberfa/erfa#43 https://github.com/liberfa/erfa/issues/43

Therefore we decided to implement our version of the BJD_TDB converter and barycentric velocity converter which always checks for leap seconds and updates if required. This is because we need codes running at remote observatories which might not always update in time and a 1 second error in time could be 3 cm/s for barycentric correction.

See - https://github.com/shbhuk/barycorrpy/wiki/5.-Leap-Second-Management

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/WarwickAstro/time-conversions/issues/1#issuecomment-395746232, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8DWNL-WbIO2CxoAY74K5gN_PvUQD8zks5t6m6CgaJpZM4Uf4_E .

[dsteeghs]

Indeed, our discussion above was about how astropy updates IERS-A on-the-fly, not relying on bundled offset files. The time conversions will use an IERS-A file that is by default at most a week old.

But now I am not sure if IERS-A is only used for UTC->UT1, and that the leap seconds come from the bundled B bulletin. If that's the case, updating IERS-A is not enough.

[dsteeghs]

Right, quick test suggests that indeed the leap-seconds are NOT updated by having a current IERS-A file...

[shbhuk]

Currently packages update the IERS tables on the fly. Indeed the leap second CAN be extracted from there, however the Astropy Time package does not extract them in that fashion.

See - https://github.com/astropy/astropy/blob/master/cextern/erfa/dat.c#L147