[Lazarus] DateDif function needed
wkitty42 at windstream.net
Thu Nov 14 21:14:02 CET 2013
On 11/14/2013 12:48 PM, Jürgen Hestermann wrote:
> Am 2013-11-14 07:56, schrieb Patrick Chevalley:
> >> So the difference between 2007-01-01 12:00 and 2008-01-01 12:00 ist
> >> *not* one year?
> > No, the base definition of the year is not a digit change,
> > but the time it take to the Earth to return at the same point of its orbit
> > around the Sun.
> Well, *this* value (earth at the same point) is also varying.
exactly! the earth does not travel in a perfect circle around the sun with the
sun in a fixed central position... then there's the tilt of the earth and that
the poles wobble around following the 25770 year equinox precession such that
Deneb will be the north pole star instead of Polaris at some point in the future
> When doing astronomical calculations I would definitely not use a fixed value.
but many do use fixed fractional average numbers to make the math easier and
they live with the small errors... witness my long posting earlier today with
the charts of days per year values and the numerous year periods ;)
> > The julian year of 365.25 is a convenient approximation still in use despite
> > the julian calendar was abrogated some 400 years ago.
> Of what use would it be to use 365.25 days as a representation of a year? You
> can also use 400 instead. It would be just an arbitrary definition decoupled
> from calendars. You cannot calculate anything useful with it. Neither calendar
> dates nor astronomical things. It is just an accademic value and exists only
> because it is "so easy to use".
i can agree with this ;)
> > All this efforts are to bypass the problem with the calendar year (the one
> > you mention) because it is sometime 365 and sometime 366 days. This is a
> > totally unacceptable definition when you need an homogeneous time scale.
> Well, that's just the whole point of this thread: The time scale we are talking
> about here is *not* homogeneous! Instead, a synchronization with calendar dates
> is wanted/needed. That has always been a problem with calendar definitons. The
> rotation of earth around the sun is not a whole-numbered multiple of its
> rotation around itself but we want a whole number of days (otherwise day time
> would no longer be related to sunlight). So we synchronize our calendar with the
> run of the sun by leap days (and leap seconds). But now years and months are no
> longer a fixed value. Therefore differences must be calculated in a more complex
> way based on dates and not as a fixed number of (milli)seconds. It's easy to use
> fixed values for day, month, year but it is of no use when talking about calendars.
i couldn't have said it better :)
> > So all depend of the use you need for your application and it must be
> > admitted that one set of definition/function is not sufficient and every one
> > must be careful when using time period.
> Just give me an example where a fixed value for a month is of use? If you rent
> an appartement you will definitely not be able to insist on your fixed
> definition of a month (i.e., when starting on february the 1st). In daily usage
> the time ranges vary depending on the month you look at.
one can see this in recurring billings... some are 30 billing periods whereas
others are monthly based where the bill is due on the same day of each month...
in the former case, the due date floats about in each successive month... the
latter is always on the X day of the month... i much prefer monthly billing over
30 day billing ;)
> > For me the very simple functions as implemented if FPC are sufficient,
> In what context do you use these functions?
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.
More information about the Lazarus