GPS-aware Python datetime module
https://git.ligo.org/cds/software/gpstime
This package provides GPS time conversion utilities, including a
gpstime subclass of the built-in datetime class with the addition of
GPS time parsing and conversion methods.
It also provides a command-line GPS conversion utility that uses the
gpstime module, a rough work-alike to LIGO "tconvert" utility.
- Sources inherited from project science
- Devel package for openSUSE:Factory
-
1
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout home:redwil:15.4/python-gpstime && cd $_ - Create Badge
Refresh
Refresh
Source Files
| Filename | Size | Changed |
|---|---|---|
| gpstime-0.6.2.tar.gz | 0000021870 21.4 KB | |
| python-gpstime.changes | 0000000160 160 Bytes | |
| python-gpstime.spec | 0000002458 2.4 KB |
Latest Revision
Dominique Leuenberger (dimstar_suse)
accepted
request 1072796
from
Atri Bhattacharya (badshah400)
(revision 2)
initialized devel package after accepting 1072796
Comments 5
I found, that tests stop working after 2023-06-28. It is about
fetch_ietf_leapfile@bmwiedemann Thanks for pointing this out. Would you mind throwing a little more light on what the specific issue will be? Perhaps we can discuss on bugzilla.o.o to figure out how to work around it.
The leapseconds files (/usr/share/zoneinfo/leap*) contains an "expires" time, which currently ist set to 2023-06-28.
This is also the reason for failing builds in Leap, as that uses the standard repository, not Update.
@bmwiedemann I think on TW its your responsibility to provide a valid timezone DB. If you advance the time to sometime in the future, you must also provide an appropriate timezone package.
Somewhat related: https://git.ligo.org/cds/software/gpstime/-/issues/16
Unfortunately, the ligo gitlab is quite closed, and reporting any issues from outsiders is near impossible.
It seems the test would only fail, as it does now on Leap, because OBS cannot fetch the required file from the web. From a user's POV, there may not be any problem because, upon finding an expired leap tz data file, this will simply download an updated one from the network and cache it to the user's config dir.
If my understanding above is correct, and in lieu of an actual fix, I think we could simply disable the specific tests that require the leap tz data when building when it starts to fail (i.e. now for Leap, later if needed for TW).
@bmwiedemann, @StefanBruens what do you think?