Talk:Calendar: Difference between revisions

From Rosetta Code
Content added Content deleted
Line 18: Line 18:
While generating a particular year is fine, a Real Programmer would not have written their calendar generator to handle arbitrary widths of display. Instead, it would have either produced for 132-char wide line printers or 80-char wide terminals. In this day and age, nobody's got line printers any more so formatting for an 80-char terminal is what we must put up with. Given that, I propose that the task should state that the calendar should be tested by generating a calendar for the current year suitable for an 80-column device. Adaptation to other widths, other years and other languages are all to be extra-credit items. –[[User:Dkf|Donal Fellows]] 08:36, 4 June 2011 (UTC)
While generating a particular year is fine, a Real Programmer would not have written their calendar generator to handle arbitrary widths of display. Instead, it would have either produced for 132-char wide line printers or 80-char wide terminals. In this day and age, nobody's got line printers any more so formatting for an 80-char terminal is what we must put up with. Given that, I propose that the task should state that the calendar should be tested by generating a calendar for the current year suitable for an 80-column device. Adaptation to other widths, other years and other languages are all to be extra-credit items. –[[User:Dkf|Donal Fellows]] 08:36, 4 June 2011 (UTC)
: Note also that the 132-column requirement would fit entirely within the scope of the dual [[CALENDAR]] task. :-) –[[User:Dkf|Donal Fellows]] 08:47, 4 June 2011 (UTC)
: Note also that the 132-column requirement would fit entirely within the scope of the dual [[CALENDAR]] task. :-) –[[User:Dkf|Donal Fellows]] 08:47, 4 June 2011 (UTC)

== Calendar versus CALENDAR ==

This task had the sentence: "For further Kudos see task [[Calendar - for "real" programmers|CALENDAR]], for printing on a 132 character width [[wp:IBM 1403|IBM 1403]] printer. Where all code and output is to be in UPPERCASE."

This sentence was wrong, because CALENDAR only requires uppercase code, not uppercase output. Also, CALENDAR is identical to Calendar (except uppercase), so if Calendar requires 80x43 output, then CALENDAR also requires 80x43 output. Before 12 June 2011, Calendar specified "a width of 132 characters". At 12 June 2011, Calendar began to require 80x43 output. This new 80x43 requirement broke the relationship between Calendar and CALENDAR, squeezed Snoopy, and ignored the line-printer Snoopy calender that inspired the task. So, I am now changing Calendar to accept either 132-wide output or 80x43 output. --[[User:Kernigh|Kernigh]] 02:00, 20 August 2011 (UTC)

Revision as of 02:00, 20 August 2011

Switch-over Complexity

Surely the date of switchover between Julian and Gregorian calendars is locale specific? For example, getting the rules right for Sweden is… “interesting” given that they tried to do the switch slowly, got distracted by a war, and then decided to switch the rest of the way at once. –Donal Fellows 13:53, 31 May 2011 (UTC)

Yes. And this reminds me of easter. --Rdm 18:22, 31 May 2011 (UTC)

Maybe a the switch over date should be an argument, defaulting to the British date of switch? I am also a bit curious as to what dating system the International Astronomical Union use. Maybe there is standard for year/date definitions in BCE and CE?

Or... Another task could be to calculate the locale date and time, based on latitude, longitude, (altitude?) AND date. Ouch... to tough for me.

NevilleDNZ 22:45, 4 June 2011 (UTC)

Conceptually, this would require a data structure which may be conceptualized as database table where the primary key was a polygon (a country's polygon) and a time interval (a time interval where that polygon defines that country's boundary). The table would also have to have a bit which indicates whether that time interval and polygon corresponds to the Julian or Gregorian calendar. All that you have to do to populate this table is find a list of all country boundaries as latitude/longitude polygons as well as how that has changed with each war or treaty settlement that has changed a country's boundary. And note that the algorithm which uses this data structure might have to return multiple values (when a border was in dispute during a region of time where one side of the border was Gregorian and the other side was Julian). An issue, of course, is that historical country boundaries might not always exactly correspond to anything we can currently unambiguously assign a latitude and longitude to (for example: when a river was the boundary -- rivers are wide and can move somewhat over the course of a century). On the other hand, this data structure can be considerably simplified where both sides of a border were using the same calendar. Nevertheless, I am not aware of any such list, and I think that this sounds like a huge historical research project. But the programming itself sounds relatively trivial (at least in comparison). --Rdm 18:44, 6 June 2011 (UTC)

Improving the task description

The task description includes these statements:

Test the calendar by generating a calendar for the year 1969 on a line printer of the time with a width of 132 characters.
Ideally the program will generate well formatted calendars for any page width from 20 characters up.
Kudos (κῦδος) for routines that also correctly transition from Julian to Gregorian calendar in September 1752.

While generating a particular year is fine, a Real Programmer would not have written their calendar generator to handle arbitrary widths of display. Instead, it would have either produced for 132-char wide line printers or 80-char wide terminals. In this day and age, nobody's got line printers any more so formatting for an 80-char terminal is what we must put up with. Given that, I propose that the task should state that the calendar should be tested by generating a calendar for the current year suitable for an 80-column device. Adaptation to other widths, other years and other languages are all to be extra-credit items. –Donal Fellows 08:36, 4 June 2011 (UTC)

Note also that the 132-column requirement would fit entirely within the scope of the dual CALENDAR task. :-) –Donal Fellows 08:47, 4 June 2011 (UTC)

Calendar versus CALENDAR

This task had the sentence: "For further Kudos see task CALENDAR, for printing on a 132 character width IBM 1403 printer. Where all code and output is to be in UPPERCASE."

This sentence was wrong, because CALENDAR only requires uppercase code, not uppercase output. Also, CALENDAR is identical to Calendar (except uppercase), so if Calendar requires 80x43 output, then CALENDAR also requires 80x43 output. Before 12 June 2011, Calendar specified "a width of 132 characters". At 12 June 2011, Calendar began to require 80x43 output. This new 80x43 requirement broke the relationship between Calendar and CALENDAR, squeezed Snoopy, and ignored the line-printer Snoopy calender that inspired the task. So, I am now changing Calendar to accept either 132-wide output or 80x43 output. --Kernigh 02:00, 20 August 2011 (UTC)