Hi,

I'm specifically looking at only situations where the year and month alone
are significant.

The downside I see with using a DateField and forcing the day to the first
of the month, with custom widget etc. is that somebody looking at the
database may not realize that something unusual is going on and I'm not
sure how I would go about finding the month x months before or after after
a given month ... solutions like

where 12 * year(t1.month_field) + month(t1.month_field) = 12 *
year(t2.month_field) + month(t2.month_field) + x

come to mind for sql but not sure how this would translate into django. Not
that I'm saying it is not the correct solution, all of the options I
considered have some downside.

The logic for adding and subtracting these "months" requires something like
timedelta(month=2), which doesn't exist in the standard library as far as I
know - though I'm not an expert.

There are recipes on stackoverflow for incrementing months though not very
elegant.

Thanks for your interest!

Matthys

On Mon, May 4, 2015 at 5:47 AM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:

> On 4/05/2015 12:31 PM, Tom Lockhart wrote:
>
>> Surely that would destroy data which wouldn’t be desirable.
>>>
>> I’m not sure how that follows.
>>
>
> If you are adjusting a date from whatever it actually is to the first of
> the month you lose the actual date.
>
> Although the question does not state
>
>> it explicitly, I believe that the OP is interested in dates for which
>> only the year and month are significant.
>>
>
> Granted. If that is correct.
>
> Saving the month as a
>
>> separate field seems to overly complicate the problem if any
>> date/time arithmetic is required.
>>
>
> Saving a date adjusted to the first of the month also involves a
> complication - or at least some work - then you extract the month to be
> displayed or queried.
>
> Extracting the month from a date is the same no matter whether it is the
> first or the ninth.
>
> Who knows when the requirements will change but you can guarantee they
> will change and Murphy's law says it will happen after you have thrown data
> away.
>
> Anyway, your choices are to calculate it every time you need it or do it
> once and use it thereafter. The right choice will depend on the
> requirements. Which will change.
>
> Cheers
>
> Mike
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/vmsiHYzI-gg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/5546EBE6.1010705%40dewhirst.com.au
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAMtJH%2BvnCsSqCsAOm9R-a2jsqWoCz9AQi19Cow75-4qQkmkQhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to