Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Meta-reply:  I am far from contributing a patch, so my
thoughts are off-topic for this list.  I am happy to take
this conversation to private email or to the discussion list
if that would better suit the list recipients.


On Thu, 2011-08-11 at 14:43 +0200, Lubos Lunak wrote:
[ Premise: If you think adding something to LO code is easy, you are still an 
inexperienced LO developer. ]

#include <tools/time.hxx>
...
printf( "%d\n", Time( 25, 0, 0 ).GetHour());
printf( "%d\n", ( Time( 1, 0, 10 ) - Time( 1, 0, 20 )).GetSec());

25
10

 As much as I don't like it, I can possibly see at least some reason for time 
having 25 hours, but 10 seconds without 20 seconds being 10 seconds (and 

Where you wrote "without", I think you mean "minus".  Right?

there is actually explicit code to ensure that)?

 Does somebody know why the Time class does either of these 

Looking only at the header, I see a function declaration
suggesting by its name and the type of its arguments that
Time is a point in time ...

    sal_Bool
    IsBetween( const Time& rFrom, const Time& rTo ) const

and a declaration suggesting by its return type that Time is
an interval ...

    TOOLS_DLLPUBLIC friend Time
    operator -( const Time& rTime1, const Time& rTime2 );

I am used to thinking of point-in-time and time-interval as
different things.  How can anything good come of it if Time
really has these two meanings?  That would require the
programmer to track which meaning a Time has at any point in
the code; this seems like unnecessary work when C++ can do
quite effective type checking for us.  General programming
maxim: make the computer do the work.

Of course, I could be misunderstanding something.  It has
been known to happen before <grin />.

                                                            and how much would 
break if I fixed these two to be sane?

opengrok shows 395 refs to symbol Time.  Imposing sanity
could be a job and a half.

OTOH, much of the work could be quite routine.  For each of
the declared variables, determine what it represents and
then declare it to be of the right type for that meaning.
If the variable carries both meanings, replace it with two
variables.

More fundamental is the question of whether the project
would rather consider together all the numerous classes
representing dates, times, and intervals.  That, of course,
would be a job and three quarters.

<ramble>

  There has been discussion on this list about easyhacks:
  who should declare a task to be "easy", and on what
  grounds.  One way to proceed--and I am *not* suggesting
  that this job should be an easyhack--might be ...

  (*) Expert creates a tracking bug and attaches two header
      files.  Perhaps they might be PointInTime.hxx and
      TimeInterval.hxx.

  (*) Expert creates numerous blocking bugs, each to replace
      Time in some part of LibreOffice.  The part of
      LibreOffice is small enough that the change can be
      easy.

  Could the job be split up so that each small part could be
  integrated without lots of--presumably temporary--conversion
  grunge at the boundaries?  I dunno; I am not the expert that
  I am talking about!

</ramble>

FWIW, this catches my interest because of interest in bug
34309 "Error on importing a timestamp field from db2 via
ODBC".  I suspect that that would lead me sooner or later to
class Time.

Cheers,
Terry.



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.