-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[WIP] Support nano second time encoding. #4400
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
Conversation
4dd19fa
to
74e9d72
Compare
Is there anything preventing to merge this? |
Oh, that requires |
But the test already passes (i.e. you can at least do a |
yeah, i'm not too sure. I think the idea is that this breaks compatibility with netcdf times, so the resulting file is thus not standard. For my application, us timing is enough. |
I think netcdf lists "nanoseconds" as a valid unit though? |
I'm working on an application where nanosecond-resolution is critical and took me days to find why my timestamps are all scrambled or off-by-1 after I write them with xarray and them read them back... would probably much rather prefer if it threw an exception instead of corrupting your data silently. Non-standard netcdf or not, if it was possible to just store them as plain int64s and read them back as is, that would help a ton... |
I think you should be able to define your own custom encoder if you want it to be a datetime. But inevitably, you will have to define your own save and load functions. Python, by definition of being such a loose language, allows you to do things that the original developers never really imagined. this can sometimes lead to silent corruption.like the one you've experienced. |
Yea, well, in this case it's not about Python... |
The merge conflict suggests this was fixed on main by #4684 |
nice! |
Not too sure i have the bandwidth to complete this seeing as cftime and datetime don't have nanoseconds, but maybe it can help somebody.
isort . && black . && mypy . && flake8
whats-new.rst
api.rst