questions re: calendar module

[Richard Damon]

On 8/2/20 5:38 PM, o1bigtenor wrote:
> On Sun, Aug 2, 2020 at 2:08 PM Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
>> On Sat, 1 Aug 2020 19:24:41 -0500, o1bigtenor <o1bigtenor at gmail.com>
>> declaimed the following:
>>
>>> It is very disappointing - - - -suggests that thinking outside the space of
>>> one year is somehow deprecated. Frustrated when what you do demands
>>> that you think in longer periods of time (and yet have to function within
>>> the week as well).
>>         Yet follows what most /print/ calendars contain (though some companies
>> put the last four months of the current year in a 4-up page, before doing
>> one month per page for the new year). "Daily planner" journals also tend to
>> cover just one year, from Jan 1 to Dec 31.
>>
>>         If you are willing to view the calendar in a browser, using
>> calendar.HTMLCalendar() may be the fastest way toward what you intend. You
>> could start, perhaps, with generating full year calendars (setting the
>> width to 12 months), and then package them as rows into an outer table
>> (granted, you won't get week numbers this way, but it may be a starting
>> point).
>> -=-=-=-
> I understand that what I'm trying to do isn't 'normal'.
> I do understand that most businesses only work with any detail in one year
> at a time.
>
> I got it!!!!
>
> That doesn't work for my situation.
>
> I tried to do this planning using 'typical software'. I about went
> crazy when I was
> trying to work looking back at one year, working in the present year
> and needing
> to drop details into the next year. (I need to work more than one year forward
> as well!)
>
> I found some very old software (cal), from the days of Unix V, with its update
> that is itself (ncal) over 10 years old.
>
> This project started when I found that I could get cal to display a
> LARGE amount
> of months except I was limited to a 80 column display. I was moaning
> to a friendof mine one time looking into how I could change the display from an
> 80 column limit to some at least 160 if not 192 columns.  One day he surprised
> me by sending me code which got this idea started. When he found out that
> week numbers were very useful - - - - they were included. He died about 3
> months ago without ever finishing the project.
>
> He liked to write in Perl albeit was comfortable in lots of other languages.
> I had talked to him about learning Python.
> So this project morphed from being in Perl (5) to being in Python.
>
> This existing code already allows me to display lots of months at a time
> with enough months width so that my terminal is 'full'. What's not there is
> the possibility of specifying a starting point to this calendar. At present
> the calendar only works from today (both backward and forward). There
> are also a few small display things I would like to tweak but the bulk of
> the idea works very well.
>
> Maybe I should be learning Perl (7) instead so I could just extend his
> work but Python seems to have more other things that it 'works' on so
> even though this makes for more work I have chosen this direction.
>
> HTH

If you don't need to produce these often, then the fastest method may be
to just build up on a spread sheet, probably less than a half hour of
work if you are at all familiar with what you are doing.

The second method would be to write a program to do this. Maybe use the
'canned' routine as a base for the program, but accept that your actual
desired output is unusual enough it won't be something you can get with
a single call. Maybe accept you can't get exactly what you want, so be
willing to accept something close. Maybe the chart goes from January of
your start year to December of the final year if the library likes doing
a full year at a time.

-- 
Richard Damon