On 28/10/2010 18:14, Eike Rathke wrote: > Hi Bartosz, > > On Wednesday, 2010-10-27 11:39:27 +0200, Bartosz wrote: > >> In tools module are utterly horrible Date/Time/DateTime classes in >> tools that could be replaced by Boost.Date_Time: > > What exactly would you describe as "utterly horrible"? Yes, they have > some ugly attributes and code..
how about the fact that DateTime is multiply inherited from Date and Time? how about the "interesting" operator overloading? or heavily-#ifdef'd implementation that could be split up into the parts that are already in osl, and the parts that are not platform specific at all? plus, the fact that these are in the "tools" module speaks for itself :) >> What do you think about idea to replace Date/Time/DateTime classes in tools >> with Boost.Date_Time? >> http://www.boost.org/doc/libs/1_44_0/doc/html/date_time.html > > Given the current implementation and use of Date/Time/DateTime I'd > consider that way overload. If replacing things at all I'd use some ICU > calendar instead as we already use that in i18n related context. > However, again, that is overload given the current use, I'd strive for > cleaning up the tools' code where necessary instead of introducing yet > unknown quirks.. hmm... i am not sure which is the right way to go here... - there are also UNO API structs in com.sun.star.util: Date, Time, and DateTime - there is some struct in osl to handle datetime stuff... in osl/time.h: oslDateTime - there is this boost thing that Bartosz found - i believe we also have a calendar API somewhere... there is also the problem that the UNO API structs cannot store any timezone information, which means we currently throw away such info in ODF files (haven't i got an issue for this...). perhaps it would be possible to create some functions that work on the UNO API structs, or the oslDateTime representation, and offer similar functionality as the tools classes, with less code duplication. having separate types for points on a timeline and durations would be nice for safety; with oslDateTime it would probably be necessary to have some wrapper classes. or perhaps it's a good idea to just use this boost library. well, with boost libraries it should first be tested if it actually works with all our compilers :) and whether error messages for simple user errors are intelligible :) don't know about other calendars; i guess those are too complex to use for simple use cases? -- "Heck, I somewhat deride the very concept of originality. Creativity is just synthesis without the introspection." -- John Carmack --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
