Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python strftime time scale #249

Closed
distbug opened this issue Jul 11, 2023 · 2 comments · Fixed by #305
Closed

Python strftime time scale #249

distbug opened this issue Jul 11, 2023 · 2 comments · Fixed by #305

Comments

@distbug
Copy link

distbug commented Jul 11, 2023

Hi,

using CPython 3.11.3 and the latest version of hifitime (3.8.2), strftime does not work with epochs using the GPST/BDT/GST time scale.

from hifitime import Epoch, TimeScale

e: Epoch = Epoch.init_from_gregorian(year=2022, month=3, day=1, hour=1, minute=1, second=59, nanos=1, time_scale=TimeScale.GPST)
print(e.strftime("%Y %m %d %H %M %S %f %T"))

Expected:
2022 03 01 01 01 59 000000001 GPST
Actual output:
1942 02 25 01 01 40 000000001 GPST

It works if the time scale is given as UTC or TAI:

e: Epoch = Epoch.init_from_gregorian(year=2022, month=3, day=1, hour=1, minute=1, second=59, nanos=1, time_scale=TimeScale.UTC)
print(e.strftime("%Y %m %d %H %M %S %f %T"))

Output:
2022 03 01 01 01 59 000000001 UTC

Similarily to_gregorian_utc_str does not work, but that is as far as I can tell related to #209

e: Epoch = Epoch.init_from_gregorian(year=2022, month=3, day=1, hour=1, minute=1, second=59, nanos=1, time_scale=TimeScale.GPST)
print(e.to_gregorian_utc_str())

Expected:
2022-03-01T01:01:41.000000001 UTC
Actual output:
2022-03-01T01:01:22.000000001 UTC

The same wrong offset of 37 seconds is used here as mentioned in the other issue.

@ChristopherRabotin
Copy link
Member

@gwbres Have you encountered this issue as well? I can start to look into it in two weeks, I'm unavailable before then.

@ChristopherRabotin
Copy link
Member

@distbug , my apologies for the delay on tackling this issue. I can confirm that this has been fixed in the upcoming version 4.0.0. I've rewritten the algorithm that computes the Gregorian days from the duration in a given time scale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants