Re: Inspiration for a better calendar package?

[m.collado@domain.invalid]

Dmitry A. Kazakov escribi�:
> On Mon, 15 Dec 2008 08:45:17 +0100, Wilhelm Spickermann wrote:
> 
>> Dmitry A. Kazakov wrote:
>>
>>> We just do not need political time otherwise than for
>>> formatted text output. ...

Agreed.

>>...
>> Additionally we should have time zone tables (without leap second
>> information) for political time (also needing the ability to
>> specify "unknown") to do conversions between "political text
>> representations of time" and "wall clock" time. It also contains
>> the completely predefined time zone "UTC".
> 
> I think it can be done much simpler. Conversion to/from political time
> should simply take time zone offset as the parameter. This is how presently
> Ada.Calendar.Formatting does. The package Ada.Calendar.Time_Zones already
> has all tables behind the function UTC_Time_Offset. The only problem is the
> argument of the function. It must be UTC time instead of political one.

Things are in fact more complex than that. The "official" or "political" 
time changes not only with the country, but also with the season, 
because of daylight savings. And the summer/winter periods change over 
years for the same country. So we need a complete history record of 
starting/ending daylight savings periods for each year and each country 
to correctly compute "political" times from UTC times. And the timezone, 
or even the calendar of a given country also changes over years.

As an example of the troubles introduced by a ill-designed time 
reporting policy, consider the way modern MS-Windows OSs report file 
timestamps. They suddently change at the last sunday of March and 
October in european countries. I once had a Modula-2 compiler system 
that unexpectedly ceased to work (reporting broken installation) after 
the first winter/summer change when I activated the "Automatic change 
time with winter/summer time".

Regards.
-- 
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado