On Mar 6, 7:24 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > Both options are supported _in many cases_. Not _all_ cases. The > Sunday=1 case is supported by all the backends.
Imho that's no real argument. Yeah, i can understand why this was choosen in the first way (because it's somehow easier to implement) but there's one thing we should not forget. The case where Monday is the first day of the week is based on "real" standards (things you can read, print out, refer to) whereas Sunday as the first day of the week isn't anything even near a standard - it just evolved over time. So from a developers point of view it's better to settle on something that is well defined. > Semmel and yourself both hang your arguments on the claim that Monday > as the start of the week is the "most supported" option, or the "most > common" option. I simply don't see any evidence that this is the case. > ISO8601 may well define Monday as the first day of the week, but > that's hardly the last word in the matter. Python itself offers two > methods for determining weekday (weekday() and isoweekday()). Common > usage (in Australia, at least) is hardly universal in nominating > Monday as the first day of the week. Well maybe it's not the "most supported" or "most common" option, we don't know that for certain. But it's the option that most of developers can use without(!) a conversion so i think we should go for that. By the way: Has anyone even noticed that in Python both weekday() and isoweekday() use Monday as the first day of the week??? So i think there should be no discussion about this anyway. Just use Python's standards and we're set. > However, for me, this is almost completely a bikeshed discussion. I > responded because I noticed the original reopen of the ticket, and I > didn't want Semmel's message to go completely unanswered. Karen made a > decision. Her decision works as designed, and it reflects the options > commonly available to database backends. Beyond that, I can't say I > really care that much - as Karen and I have both said, no matter what > decision is made, somebody isn't going to be happy, but the good news > is that the calculation required to rectify results isn't that hard. Just one question: WHY should it reflect the options available for the database backends? Since you want to work with that stuff on Python's side it should reflect the options given by Python. So that makes absolutely no sense! That's no discussion about wether one will be unhappy or not - it's just against common sense. That's why i find that decision so weird. I respect Karen's decision but it don't think that all points where thought through. Just to note: I am pushing this discussion as we will be stuck with it when 1.1 is released and i don't want this to happen with an imho flawed implementation. Regards, Semmel --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
