This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: yday in datetime module
Type: enhancement Stage: patch review
Components: Documentation, Library (Lib) Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: belopolsky, georg.brandl, jborgohain, lemburg, mark.dickinson, mwtoews, pitrou
Priority: normal Keywords: needs review, patch

Created on 2006-02-22 02:58 by mwtoews, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue1436346.diff jborgohain, 2009-07-20 01:46 Patch contains new additions to datetimemodule.c and also new test cases have been added.
issue1436346-doc.diff belopolsky, 2010-05-23 17:16 Documentation patch against the trunk
Messages (11)
msg61219 - (view) Author: Michael Toews (mwtoews) Date: 2006-02-22 02:58
My first request is relatively simple: add a 'yday'
method to datetime.date and datetime.datetime.
Thus I could do:

>>> from datetime import *

>>> t = date.today()
>>> t.yday()
52

# rather than the less readable:
>>> t.timetuple()[7]
52

# or worse:
>>> int(t.strftime('%j'))
52


The second request is to have more alternate
constructors for date or datetime objects. There are
currently:
  * date(year,month,day)
  * date.fromtimestamp(timestamp)
  * date.fromordinal(ordinal)
  * date.today()

I would like to have:
  * date.fromtimetuple(9-item time tuple structure)
  * date.strptime(data_string,format)


As well, it would be nice to change:
  * date(year,month=None,day=None,yday=None)

e.g.,:
>>> date(2006,2,21) == date(2006,yday=52)
True

Here, a date can be formed from a year, month and day
or from just the year and the day of the year,
otherwise I have to convert using:
>>> import time
>>> year = 2006
>>> yday = 52
>>> t = time.strptime(`year`+'-'+`yday`,'%Y-%j')
>>> datetime.date(t.tm_year,t.tm_mon,t.tm_mday)
datetime.date(2006, 2, 21)

If a safer approach is desired (as to not change the
class constructor too much), then please offer an
alternate, say:
  * date.fromyday(year,yday)

or something like that.

Thanks.
+mt
msg90720 - (view) Author: Jubaraj Borgohain (jborgohain) Date: 2009-07-20 01:46
I have completed the following two new features for the datetime module
(the changes are attached as a patch):
a. Added a method yday()
b. Added date.fromyday(year,yday), which returns a date object.
The other features requested are already available.
The tests for these two new features have also been added to
test_datetimemodule.py.
The patch has been only tested on trunk.(Python 2.7)
msg91309 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-08-05 10:52
Some comments:
- since there is already a weekday() method, the new method should be
called yearday() rather than yday()
- ditto for fromyday(): fromyearday() would be better
- Modules/datetimemodule.c should only be indented with tabs, but your
patch indents it with spaces in some places
- the algorithm in date_fromyday() looks suboptimal: if you repeatedly
call days_in_month(), you shouldn't have to call days_before_month() at
the end, you can compute it by yourself

I haven't tested the patch yet.

Marc-André, do you have any take on the principle of this?
msg91313 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2009-08-05 11:06
Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
> Some comments:
> - since there is already a weekday() method, the new method should be
> called yearday() rather than yday()
> - ditto for fromyday(): fromyearday() would be better
> - Modules/datetimemodule.c should only be indented with tabs, but your
> patch indents it with spaces in some places
> - the algorithm in date_fromyday() looks suboptimal: if you repeatedly
> call days_in_month(), you shouldn't have to call days_before_month() at
> the end, you can compute it by yourself
> 
> I haven't tested the patch yet.
> 
> Marc-André, do you have any take on the principle of this?

mxDateTime uses attributes for such things, ie. .day_of_week,
.day_of_year, .days_in_month. No idea, why the datetime module
chose to implement access to this static information as method.

I've never had a request for a way to construct a date by
giving the year and day of the year - probably because it's
just too easy to do by hand:

217
>>> Date(2009, 1, 1) + (217 - 1)
<mx.DateTime.DateTime object for '2009-08-05 00:00:00.00' at 2b5320c262f0>
msg91314 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2009-08-05 11:09
Hmm, looks like there's a bug in roundup's email interface... the code
snippet should have read:

>>> from mx.DateTime import *
>>> today().day_of_year
217
>>> Date(2009, 1, 1) + (217 - 1)
<mx.DateTime.DateTime object for '2009-08-05 00:00:00.00' at 2b5320c262f0>
msg106206 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-05-20 23:17
I think this should be rejected.  The OP's premise was that t.timetuple()[7] was unreadable, but in the modern python, the same can be written as t.timetuple().tm_yday.  The later is only slightly less readable than the proposed t.yday().

For the other half of the proposal, Marc-Andre's mxDate code translates into only slightly more complicated stdlib datetime code:

def date_fromyday(year, yday):
   return date(year, 1, 1) + timedelta(yday - 1)
msg106207 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-05-20 23:27
> I think this should be rejected.  The OP's premise was that
> t.timetuple()[7] was unreadable, but in the modern python, the same
> can be written as t.timetuple().tm_yday.

Could I suggest such example be added to the documentation, though?
The datetime / time jungle is difficult to navigate through, and I think
for most people it is not obvious that the answer to their needs is to
look at one of the attributes of the timetuple() result...
msg106258 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-05-21 19:58
On Thu, May 20, 2010 at 7:27 PM, Antoine Pitrou <report@bugs.python.org> wrote:
>
>> .. The OP's premise was that
>> t.timetuple()[7] was unreadable, but in the modern python, the same
>> can be written as t.timetuple().tm_yday.
>
> Could I suggest such example be added to the documentation, though?

The documentation for timetuple method [1, 2] already contains a
recipe for computing yday which is more efficient than
t.timetuple().tm_yday:

 yday = d.toordinal() - date(d.year, 1, 1).toordinal() + 1

Maybe it can be improved by making it discoverable in searches for yday:

"""
... is equivalent to time.struct_time((d.year, d.month, d.day, d.hour,
d.minute, d.second, d.weekday(), yday, dst)), where yday =
d.toordinal() - date(d.year, 1, 1).toordinal() + 1 is the day number
of the year starting from 1 for January 1st.
"""

[1] http://docs.python.org/py3k/library/datetime.html#datetime.date.timetuple
[2] http://docs.python.org/py3k/library/datetime.html#datetime.datetime.timetuple
msg106288 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-05-22 08:21
Care to suggest a patch?
msg106338 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-05-23 17:16
Attaching a documentation patch.
msg106341 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-05-23 21:55
Committed in r81489.  Thanks!
History
Date User Action Args
2022-04-11 14:56:15adminsetgithub: 42934
2010-05-23 21:55:55georg.brandlsetstatus: open -> closed
resolution: fixed
messages: + msg106341
2010-05-23 17:18:00belopolskysetkeywords: + needs review
assignee: belopolsky ->
versions: + Python 2.7
components: + Documentation
nosy: lemburg, georg.brandl, mark.dickinson, belopolsky, pitrou, mwtoews, jborgohain
2010-05-23 17:16:24belopolskysetfiles: + issue1436346-doc.diff

messages: + msg106338
2010-05-22 08:21:22georg.brandlsetmessages: + msg106288
2010-05-21 20:05:58belopolskysetnosy: + georg.brandl
2010-05-21 19:58:04belopolskysetmessages: + msg106258
2010-05-20 23:27:16pitrousetmessages: + msg106207
2010-05-20 23:17:45belopolskysetmessages: + msg106206
2010-05-20 22:42:41belopolskysetassignee: belopolsky
2010-05-20 22:24:02pitrousetnosy: + mark.dickinson, belopolsky

versions: - Python 2.7
2009-08-05 11:09:25lemburgsetmessages: + msg91314
2009-08-05 11:06:56lemburgsetmessages: + msg91313
2009-08-05 10:52:48pitrousetnosy: + lemburg

messages: + msg91309
stage: test needed -> patch review
2009-07-24 08:29:00pitrousetnosy: + pitrou

versions: + Python 3.2, - Python 3.1
2009-07-20 01:46:54jborgohainsetfiles: + issue1436346.diff

nosy: + jborgohain
messages: + msg90720

keywords: + patch
2009-03-21 00:36:50ajaksu2setstage: test needed
versions: + Python 3.1, Python 2.7
2006-02-22 02:58:43mwtoewscreate