Disable/skip time-dependent tests (e.g. test_iers_b_out_of_range_handling)

Description

test_iers_b_out_of_range_handling is a "time bomb" test that starts failing after a certain amount of time:

astropy/astropy/utils/iers/tests/test_iers.py

Lines 507 to 516 in bf1d238

    
           def test_iers_b_out_of_range_handling(): 
        
               # The following error/warning applies only to IERS_B, not to the default IERS_Auto 
        
               with iers.earth_orientation_table.set(iers.IERS_B.open()): 
        
                   now = Time.now() 
        
                   # Should be fine with bundled IERS-B 
        
                   (now - 300 * u.day).ut1 
        
                   # Default is to raise an error 
        
                   match = r"\(some\) times are outside of range covered by IERS table"

That is not great for reproducible builds, especially for Linux distributions.

NixOS example:

python3Packages.astropy: disable build-date-dependent irreproducible test NixOS/nixpkgs#579447

In this case, the failing time-based test (test_iers_b_out_of_range_handling) is holding up the testing and release of the critical brotli security vulnerability CVE-2026-111497.

It would be nice if tests could be written such that they do not fail after a certain amount of time, so software stays reproducible.

Expected behavior

No response

How to Reproduce

Get package from '...'
Then run '...'
An error occurs.

# Put your Python code snippet here.

Versions

import astropy
astropy.system_info()

# Paste the result here

python3Packages.astropy: disable build-date-dependent irreproducible …

@olebole

Can't you just skip it in your distro? I think @olebole skip some tests for Debian.

Yes, this is true. We use this patch to disable tests that may fail in the future.

This however affects all distributions, so it may be however a good idea to flag these tests upstream for a pytest filter.

Can't you just skip it in your distro?

Yes, that's what the PR I linked does.

My main point though is to question whether it's actually a good idea to have time bomb tests at all. It seems to run fundamentally against the idea of reproducibility, which is a good thing for distributions and upstreams alike.

E.g. for a given table, wouldn't it be more sensible to check that it does its job for the range it covers, instead of making a test that checks if it works today?

Hmm... I guess we could add some env var you can use for skipping. There is precedent here:

astropy/astropy/tests/helper.py

Lines 28 to 29 in 47567cd

    
           CI = os.environ.get("CI", "false") == "true" 
        
           IS_CRON = os.environ.get("IS_CRON", "false") == "true"

Ideas welcome.

@mhvk

wouldn't it be more sensible to check that it does its job for the range it covers

I'll defer to wisdom of @mhvk for this one.

Navigation Menu

Repository navigation

Disable/skip time-dependent tests (e.g. `test_iers_b_out_of_range_handling`) #20725

Description

Expected behavior

How to Reproduce

Versions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	def test_iers_b_out_of_range_handling():
	# The following error/warning applies only to IERS_B, not to the default IERS_Auto
	with iers.earth_orientation_table.set(iers.IERS_B.open()):
	now = Time.now()

	# Should be fine with bundled IERS-B
	(now - 300 * u.day).ut1

	# Default is to raise an error
	match = r"\(some\) times are outside of range covered by IERS table"

	CI = os.environ.get("CI", "false") == "true"
	IS_CRON = os.environ.get("IS_CRON", "false") == "true"

Disable/skip time-dependent tests (e.g. test_iers_b_out_of_range_handling) #20725

Description

Description

Expected behavior

How to Reproduce

Versions

Activity

pllim commented on Oct 27, 2026

olebole commented on Oct 27, 2026

nh2 commented on Oct 27, 2026

pllim commented on Oct 27, 2026

pllim commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Disable/skip time-dependent tests (e.g. `test_iers_b_out_of_range_handling`) #20725