[Freeciv-Dev] Re: (PR#2912) Remove last traces of year usage

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

Raimar Falke wrote:
> On Sat, Feb 15, 2003 at 12:51:48AM -0800, Jason Short via RT wrote:
> 
>>[rfalke - Sat Feb  1 13:48:47 2003]:
>>
>>
>>>On Mon, Jan 27, 2003 at 12:13:25PM -0800, Per I. Mathisen via RT wrote:
>>>
>>>>Inconsistency between "endyear" and "onsetbarbs". One wants years, the
>>>>other was changed to turns.
> 
> 
>>>I'm for changing everything to turns.
> 
> 
> I remembered one reason against this change. You can't specify the
> year 2000 as endyear. This may be required for
> historical/compatibility reasons.

Seems like this could be part of the gen-calendar change, specifying 
starttime, intervals, and endtime for the scenario.  To begin with we 
would have startyear and endyear as the server options, while the 
intervals are fixed (50 year intervals until -1000, 25 year intervals 
until 0, 20 year intervals until 1000, 10 year intervals until 1500, 5 
year intervals until 1750, 2 year intervals until 1900, 1-year intervals 
after that).  The conversion year<->turn can be done as an O(n) process 
where n is the number of intervals.

>>As a side question, in the comment:
>>
>>+/***************************************************************
>>+  turn_to_year and year_to_turn assume a standard (from -2000 to
>>+  4000) game where the spaceshipparts doesn't change the anything.
>>+
>>+  ONLY USE THESE FUNCTIONS FOR BACKWARDS COMPATIBILITY.
>>+
>>+  Move the functions to server/savegame.c if the "year2turn"
>>+  capability is removed.
>>+***************************************************************/
>>+int turn_to_year(int turn)
>>
>>What does the bit about moving to server/savegame.c mean?  The year2turn
>>capability was just added; it seems unlikely that it would be dropped in
>>the future.  Do you mean it will become a manditory capability and
>>eventually be supplanted by a +1.15.0 (or similar) capability?
> 
> 
> If the capability is non-mandatory than two areas still operate with
> year and so need turn_to_year: network and savegames. The network will
> be removed in this if we remove the non-mandatory capability at the
> time of the next release.
> 
> Mike had suggested and I agree with him that it is easier to just add
> a manditory capability. This way only the savegame loading will need
> the mapping turn-to-year.

What about the UI?

>>And how could this function every leave the client; doesn't the
>>client need to know about the calendar?
> 
> 
> The client (like the rest of the code) operates on turns only. Only
> for certain activities a pretty printed turn (the date, years here)
> are needed. The client only needs the date of the current turn. The
> server sends this to the client as a string.

So the client is only able to determine the year for the current turn? 
That seems like an unnecessary restriction just so that turn_to_year can 
be moved into the server.  Information like what year a city was 
founded, what year a spaceship will arrive, etc., is not essential but 
is good to be able to give the user.

jason