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

datetime object dayofyear and dayofwk issue #13

Closed
djkirkham opened this issue Mar 31, 2017 · 3 comments
Closed

datetime object dayofyear and dayofwk issue #13

djkirkham opened this issue Mar 31, 2017 · 3 comments

Comments

@djkirkham
Copy link

netcdftime.datetime objects constructed directly don't have the correct day of year or day of week; they always give a value of 1 and -1 respectively. Objects returned by utime.num2date have the correct values, except for those with Julian calendars, which still have the issue.

>>> import netcdftime
>>> print netcdftime.__version__
1.4.1
>>> date = netcdftime.DatetimeNoLeap(2000, 1, 2)
>>> print repr(date)
netcdftime._netcdftime.DatetimeNoLeap(2000, 1, 2, 0, 0, 0, 0, -1, 1)
>>> print date.dayofyr 
1
>>> print date.dayofwk
-1

Python version: 2.7
netdf4 version: 1.2.7
Installed via conda forge.

@jswhit
Copy link
Collaborator

jswhit commented Aug 16, 2018

The dayofwk and dayofyr values only get calculated when the routine is called to convert a Julian day number to a date (i.e. num2date). The only way that cftime.DatetimeNoLeap will have the correct values is if they are passed into __init__. This may be a flaw in the design, but that's the way it is for now.

@jswhit
Copy link
Collaborator

jswhit commented Aug 16, 2018

After looking into this a bit more, it seems to me that the dayofwk and dayofyr support is half-baked at best. These attributes are not provided by the python datetime object, so perhaps we should just remove them. I wonder if anyone is actually using this?

jswhit added a commit that referenced this issue Aug 20, 2018
fix dayofwk calculation (issue #13)
@jswhit
Copy link
Collaborator

jswhit commented Aug 20, 2018

This is fixed by pull request #66, closingnow.

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

No branches or pull requests

2 participants