Opened 16 years ago
Closed 16 years ago
#10345 closed (wontfix)
'week_day' lookup type should use python's values for lookup
Reported by: | Florian Sening | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Keywords: | weekday lookup | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
#7672 introduced a new lookup type for weekdays that was committed in [9818]. The problem are that values that it uses. There already was some discussion about the values but they eventually settled on Sunday=1 and Saturday=6. Imho this is not the best decision. Of course it is obvious that they ended up with these values because that's what the databases are using mostly but there are problems when used with e.g. Python internals.
Python always starts with Monday being the first day of the week whether you use weekday() (Monday=0) or isoweekday() (Monday=1). The Python behaviour also conforms to national/international standards and recommendations like ISO 8601 or DIN 1355 where it also starts with Monday being the first day of the week.
I looked at the code and i know that it requires some conversion and changes for this but it would be even worse if you had to do that conversion every time you're using that django feature. So my suggestions is to change the behaviour to that of Python's weekday().
Change History (4)
comment:1 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:3 by , 16 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Of course i have carefully read the reasons why it was chosen. It still think that this is not the "right" choice but maybe it didn't make it that clear why it is important.
First of all you're right with the standards because one group will always be unhappy. But there are some little things which makes the week starting with Monday the better choice.
- The "external" representation of weekday is derived from the internal use of weekday. So the abstraction is wrong because you work with Django's objects - not with the database directly. That's no good code. It shouldn't rely on each other or at least one should not rely on the other.
- There is no standard for databases that says Sunday should be the first day of the week. So what happens if there is going to be a standard (that's likely going to be Monday as the first day of the week - see next point)? Will the code be changed? Of course not - but you'll need to do a conversion on both sides of the code. That makes it clear why the previous point is so important.
- Monday as the first day currently is the de facto Standard for nearly everything and it's getting more and more common. Beside the databases there are only few things that implement it that way (as far as i know).
- There are official standards (as i stated in my previous statement) for this. And they all say that Monday is the first day of the week. Most of the time it's better to rely on official rather than de facto standards (that, in fact, are only used by a few databases).
- You always have to make a conversion when you work with it (as shown in your example). Of course that conversion is trivial (as you showed us) but it's something you have to do every time! That's no good code either. Recurring code like this should go inside the implementation (Django) and does not belong in the user's code (to take the complexity and unnecessary work out of user's code).
There's only one(!) reason (and that's no "real" reason because the implementation is trivial for both sides of the code) why you would want to start the week with Sunday and that's because it's easier to implement since most databases use the week that way. You're somehow right when you say that this is no big deal but there are so many reasons that speak against it. Remember when IE was famous? It's just like that. There was the de facto standard and everybody did it that way and then some guys come along and say "whoa - that's not standard what you're doing here". And now look at the mess we've got. I personally curse IE nearly everyday for being so shiy - so maybe that's way i'm so stubborn with "standard choices" like this. Well ... maybe the example is a bit extreme but i think you get the point.
If somebody thinks there are reasons why you should implement it the other way (Sunday as first day) and can prove his claims then please tell me.
comment:4 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Please don't reopen tickets that have been closed by a core committer. If you disagree with a decision, start a thread on django-developers.
Wherever multiple standards (be they de facto or "official") exist and one has to be chosen, some group is not going to be happy with the choice. The table here:
http://code.djangoproject.com/ticket/7672#comment:3
provides a nice overview of the variety of "standards" to choose from, and makes it pretty clear why 1-7 with Sunday=1 was chosen here. Namely, it is one of the options provided by all of the DBs (therefore likely familiar to anyone coming from the DB side), plus it is very simple to transform from Python's isoweekday() to the chosen form. So say, for example, I wanted to implement a "find other puzzles like this one" search for my puzzle database site. I'd want, given a puzzle, to find other puzzles with the same author, in the same publication, on the same day of the week (since most pubs have a difficulty scale that increases as the week goes on). This is easily done:
Sure, it's a bit of a nuisance that I have to transform the isoweekday() output, but it isn't that hard. So I don't quite see how the choice made here causes "problems when used with e.g. Python internals".
I think no matter what was chosen here, someone would be unhappy, and I don't see that a compelling case for switching has been made here. If you've got something you think you absolutely cannot do given the choice made here, you need to spell it out in more detail.