An enhancement request to make available the date of the first iso weekday of any week of any year.

I have made a patch as per the "Lifecycle of a patch" quick guide.
(http://docs.python.org/devguide/patch.html#lifecycle-of-a-patch)

Patch updated with sanity checks.

Patch updated with tests and documentation

Some comments:

- you also need to modify the C version in Modules/_datetimemodule.c
(make sure the tests exercise both versions!)

- the doc needs a "versionadded" tag

- I don't understand this:

+        if self.isocalendar()[1] != 1:
+            if self.weekday() > 3:  # Jan 1 is not in week one
+                self += timedelta(7 - self.weekday())

What if self.weekday() <= 3 ? Surely some adjustment is needed as well?
(you should probably add more tests to cover the various cases)

- this comment:

+        # Test that we get the OverflowError when the year has 52 weeks

seems wrong since ValueError is raised

Before you invest in a C version, let's discuss whether this feature is desirable.  The proposed function implements a very simple and not very common calculation.  Note that even dateutil does not provide direct support for this: you are instructed to use relativedelta to add weeks to January 1st of the given year.

If we are going to add yet another way to construct dates, I would like to consider some universal solution.  For example, a "make_date" function that would behave similar to the timedelta constructor: take a large number of keyword arguments and return a date.  For example,

make_date(year=2000, isoweek=5, weekday=3)
make_date(year=2000, isoday=63)
etc.

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <alexander.belopolsky@gmail.com> added the comment:
> 
> Before you invest in a C version, let's discuss whether this feature is desirable.  The proposed function implements a very simple and not very common calculation.  Note that even dateutil does not provide direct support for this: you are instructed to use relativedelta to add weeks to January 1st of the given year.

Which is wrong, since the start of the first ISO week of a year
can in fact start in the preceeding year...

http://en.wikipedia.org/wiki/ISO_week_date

and it's not a simple calculation.

ISO weeks are in common use throughout Europe, it's part of the
ISO 8601 standard. mxDateTime has had such constructors for ages:

http://www.egenix.com/products/python/mxBase/mxDateTime/doc/#_Toc293683820

On Mon, Apr 9, 2012 at 6:20 PM, Marc-Andre Lemburg
<report@bugs.python.org> wrote:
> Which is wrong, since the start of the first ISO week of a year
> can in fact start in the preceeding year...

Hmm, the dateutil documentation seems to imply that relativedelta
takes care of this:

http://labix.org/python-dateutil#head-72c4689ec5608067d118b9143cef6bdffb6dad4e

(Search the page for "ISO")

> Hmm, the dateutil documentation seems to imply that relativedelta
> takes care of this:

This is all a bit moot since we don't have a "relativedelta" in the
stdlib.
I think the two questions here are:
- is this feature desirable? I think the answer is "yes"
- is the implementation correct? I don't know :-)

Talk of a magical generic constructor sounds a bit futile to me,
especially if the constructor's behaviour becomes so complicated that
it's difficult to understand for users...

On Mon, Apr 9, 2012 at 6:56 PM, Antoine Pitrou <report@bugs.python.org> wrote:
> This is all a bit moot since we don't have a "relativedelta" in the
> stdlib.

It is still worthwhile to see how it is done elsewhere.  So far, we
have dateutil that does not have this function and mxDateTime that
keeps this and other ISO related functions in a submodule.  Does
anyone know how this is done in other languages?

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <alexander.belopolsky@gmail.com> added the comment:
> 
> On Mon, Apr 9, 2012 at 6:20 PM, Marc-Andre Lemburg
> <report@bugs.python.org> wrote:
>> Which is wrong, since the start of the first ISO week of a year
>> can in fact start in the preceeding year...
> 
> Hmm, the dateutil documentation seems to imply that relativedelta
> takes care of this:
> 
> http://labix.org/python-dateutil#head-72c4689ec5608067d118b9143cef6bdffb6dad4e
> 
> (Search the page for "ISO")

That's not realtivedelta taking care of it, it's the way it is
used: the week with 4.1. in it is the first ISO week of a year;
it then goes back to the previous Monday and adds 14 weeks from
there to go to the Monday of the 15th week. This works fine as
long as 4.1. doesn't fall on a Monday...

You don't really expect anyone to remember such rules, do you ? :-)

On Mon, Apr 9, 2012 at 7:28 PM, Marc-Andre Lemburg
<report@bugs.python.org> wrote:
> You don't really expect anyone to remember such rules, do you ? :-)

No, but it is still a one-line function that those who need it can
easily implement.  I am on the fence here because we already have
date.isocalendar() function, so it is natural to desire its inverse,
but still at least on this side of the pond an Easter(year) date
constructor would see more use than that.

I believe that it is a good solution to have, for lack of a better term;
bi-directional features so
in my opinion .isocalendar()  merits having a constructor that takes an ISO
format.

Sadly no :-(
I looked it over once more and it seems there is an error where the date is
not offset correctly
for years beginning on Tuesday, Wednesday or Thursday.
I will updater my patch ASAP.

+        if self.isocalendar()[1] != 1:
+            if self.weekday() > 3:  # Jan 1 is not in week one

+                 self += timedelta(7 - self.weekday())

+        else:

+            self -= timedelta(self.weekday())

----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue14423>
> _______________________________________
>

> No, but it is still a one-line function that those who need it can
> easily implement.

It's so easy that the patch isn't a one-liner and it seems to still have
bugs wrt. intended behaviour.

>   I am on the fence here because we already have
> date.isocalendar() function, so it is natural to desire its inverse,
> but still at least on this side of the pond an Easter(year) date
> constructor would see more use than that.

This isn't an either/or situation. We can have both from_iso_week() and
Easter() if both are useful.
And I don't get this "side of the pond" argument. Python is not meant
only for the American public, that's why all strings are now unicode.

On Tue, Apr 10, 2012 at 6:44 AM, Antoine Pitrou <report@bugs.python.org> wrote:
> It's so easy that the patch isn't a one-liner and it seems to still have
> bugs wrt. intended behaviour.

Unless I miss something, the inverse to isocalendar() is simply

from datetime import *

def fromiso(year, week, day):
    d = date(year, 1, 4)
    return d + timedelta((week - 1) * 7 + day - d.isoweekday())

At least it works in my testing:

(2012, 15, 2)

1) Yes I agree, your solution is somewhat more concise, I have corrected
the code accordingly.
2) I get errors for all my test when I build "my" python and run
"./python.exe -m test.datetimetester -j3"
    I asume this is because I have yet to implement the c version in
Modules/_datetimemodule.c
    is this the correct assumption?

Kind regards

On Tue, Apr 10, 2012 at 3:32 PM, Alexander Belopolsky <
report@bugs.python.org> wrote:

>
> Alexander Belopolsky <alexander.belopolsky@gmail.com> added the comment:
>
> On Tue, Apr 10, 2012 at 6:44 AM, Antoine Pitrou <report@bugs.python.org>
> wrote:
> > It's so easy that the patch isn't a one-liner and it seems to still have
> > bugs wrt. intended behaviour.
>
> Unless I miss something, the inverse to isocalendar() is simply
>
> from datetime import *
>
> def fromiso(year, week, day):
>    d = date(year, 1, 4)
>    return d + timedelta((week - 1) * 7 + day - d.isoweekday())
>
> At least it works in my testing:
>
> (2012, 15, 2)
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue14423>
> _______________________________________
>

> 1) Yes I agree, your solution is somewhat more concise, I have corrected
> the code accordingly.
> 2) I get errors for all my test when I build "my" python and run
> "./python.exe -m test.datetimetester -j3"
>     I asume this is because I have yet to implement the c version in
> Modules/_datetimemodule.c
>     is this the correct assumption?

You should probably run "./python.exe -m test -v test_datetime" instead.
Not sure that will fix your test failures, though :)

>> 2) I get errors for all my test when I build "my" python and run
>> "./python.exe -m test.datetimetester -j3"
>>     I asume this is because I have yet to implement the c version in
>> Modules/_datetimemodule.c
>>     is this the correct assumption?

>You should probably run "./python.exe -m test -v test_datetime" instead.
>Not sure that will fix your test failures, though :)

Ok so now i only get errors for "_Fast" tests am I correct in assuming that this is because i lack a C implementation?

> Ok so now i only get errors for "_Fast" tests
> am I correct in assuming that this is because i lack a C implementation?

If your errors look like the one below, then yes.


======================================================================
ERROR: test_from_iso_week_value_week (test.datetimetester.TestDate_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/mdickinson/Python/cpython/Lib/test/datetimetester.py", line 1000, in test_from_iso_week_value_week
    self.assertRaises(ValueError, self.theclass.from_iso_week, year,
AttributeError: type object 'datetime.date' has no attribute 'from_iso_week'

By the way, I don't think the algorithm used in the current patch is correct.  For 'date.from_iso_week(2009, 1)' I get 2009/1/1, which was a Thursday.  The documentation seems to indicate that a Monday should be returned.

Mark Dickinson wrote:
> 
> By the way, I don't think the algorithm used in the current patch is correct.  For 'date.from_iso_week(2009, 1)' I get 2009/1/1, which was a Thursday.  The documentation seems to indicate that a Monday should be returned.

True, the correct date is 2008-12-29.

I somehow re-uploaded an old patch,
this one contains buggy c-code, but fixes the python implementation.

Any pointers to how to get started on the c bi would be greatly appreciated.

I would like to point out that http://bugs.python.org/issue12006 provides a solution (including patches) based on %G%, V and %u directives for use in strptime()/strftime(). These directives are defined in (FreeBSD) libc, and PHP has them, too.

I think the strptime approach is a more elegant and standardized way of creating dates from exotic values.

I am rejecting this in favor of #12006.