[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] About non-gregorian calendar systems
From:       Frans de Wet <Frans () de-Wet ! com>
Date:       2002-02-26 13:18:51
[Download RAW message or body]

Hi there,

I have been thinking about this date thing for a while and I do not really 
have a solution ... just a bunch of ideas.  

If we create a object for each date type that would not in itself help much.  
When programming a user interface it would be much to complicated to make use 
of this easily.  The only way I would really be willing to use this would be 
if the class KDate or CalendarSystem (I like this more) encompassed all of 
this, and provided a single access point for all the different date types.  
The class CalendarSytem or Kdate would have to look very much, if not exactly 
like QDate to be backwards compatible and provide a logical upgrade path.  In 
addition I would want to be able to say something to the extent of 

aDate.getYear(HELLENIC); //Return the hellenic year
aDate.getYear(); // Return the Gregorian year (this is the way QDate works)

The type on all of these functions would be an optional parameter.  That way 
I only have to store what representation the user would want the calendar in 
and get the calendar structure, days per year, days per months, days per 
week, name of the months, name of the years, name of the days etc.   I can 
curently ask QDate to give me the date in a string format, like "January 15, 
2002" can't I.  That means the date should implicitely know the calendar 
format it uses. 

So, if I look at this from a requirement side it makes sense to my warped 
brain that I do not want to have 10 different classes or types of calendars 
to worry about when writing a program, I only want to worry about one.  As 
such I do not want to  have to go from CalendarSystem to HCalendarSystem to 
get a hellenic representation and from CalendarSystem to GCalendarSystem tto 
get the Grogorian representation etc ... I want to only use one class which 
could be CalendarSystem or KDate and it should handle all the complexities 
for me.  I do not want to change my code when a new date/calendar system is 
developed, I just want the new date system to show up in a list box somewhere 
and if the user selects it that is stored as a preference.  I will then draw 
the calendar and convert all the dates to what the user selected by just 
passing the users preference to all the functions.  

Am I being totally silly ... and does any of this make sense.  Can I do this 
in C++ and I just missed a whole big part of my training? (hehehe)

So, if I was to write this I would try to make it as easy as pie from the 
frontend to convert between dates.  This would be accomplished by just 
specifying a type (or not).  This can then be used to convert between date 
formats too ... by loading (or constructing) the date object with a specific 
date type (which is then converted and stored in QDate format) and then 
retriieving it with another type specified.  No casting and the type is 
transparent and not dependent on the code of the final application.

See ya,
Frans
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]