On 18/11/13 16:46, Hans-Peter Diettrich wrote:
Jürgen Hestermann schrieb:
I still find CalenderDiff the best name for this function
because it clearly states that differences are calculated for calender
dates and not for an homogeneous stream of seconds/hours/days.
This raises immediately
On 11/16/2013 06:40 PM, Michael Van Canneyt wrote:
I think it's fairly simple, really. ...
This does make some sense, even for me :-)
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
2013/11/18 Michael Schnell mschn...@lumino.de
On 11/16/2013 06:40 PM, Michael Van Canneyt wrote:
I think it's fairly simple, really. ...
This does make some sense, even for me :-)
I ask in advance all those who thought that this thread was finally dead to
excuse me.
I have been working
On 18.11.2013 13:11, Frederic Da Vitoria wrote:
procedure DatesToAge (Date1, Date2: TDate ; out Years, Months, Days:
integer);
var
Hi Frederic,
your code works as aspected!
Perhaps it's more usual if you change the out Parameters to word?!
Regards
John
--
2013/11/18 John Landmesser joh...@online.de
On 18.11.2013 13:11, Frederic Da Vitoria wrote:
procedure DatesToAge (Date1, Date2: TDate ; out Years, Months, Days:
integer);
var
Hi Frederic,
your code works as aspected!
Perhaps it's more usual if you change the out Parameters to word?
Jürgen Hestermann schrieb:
I still find CalenderDiff the best name for this function
because it clearly states that differences are calculated for calender
dates and not for an homogeneous stream of seconds/hours/days.
This raises immediately the next question: which calendar?
DoDi
--
Il 18/11/2013 17:46, Hans-Peter Diettrich ha scritto:
Jürgen Hestermann schrieb:
I still find CalenderDiff the best name for this function
because it clearly states that differences are calculated for calender
dates and not for an homogeneous stream of seconds/hours/days.
This raises
On 11/18/2013 11:46 AM, Hans-Peter Diettrich wrote:
Jürgen Hestermann schrieb:
I still find CalenderDiff the best name for this function
because it clearly states that differences are calculated for calender
dates and not for an homogeneous stream of seconds/hours/days.
This raises
Am 2013-11-18 17:46, schrieb Hans-Peter Diettrich:
Jürgen Hestermann schrieb:
I still find CalenderDiff the best name for this function
because it clearly states that differences are calculated for calender
dates and not for an homogeneous stream of seconds/hours/days.
This raises
waldo kitty schrieb:
On 11/18/2013 11:46 AM, Hans-Peter Diettrich wrote:
Jürgen Hestermann schrieb:
I still find CalenderDiff the best name for this function
because it clearly states that differences are calculated for calender
dates and not for an homogeneous stream of seconds/hours/days.
On 08.11.2013 21:35, John Landmesser wrote:
Hi List,
i'm searching a pascal datetime function that simulates an Excel
function: DateDif
Excel for example knows the function DateDif that returns the number
of Years, month and days between Date1 and date2.
Date1 := 21.12.2012
Date2 :=
On 11/16/2013 5:08 AM, John Landmesser wrote:
This discussion seems to be finished ( 92 posts ) and i want to make a proposal
as solution:
Use the function DateDiff from Jedi ( RxLib ) ( JvJCLUtils.pas ).
that routine is actually a procedure... the one i posted is a function that
returns the
On 11/16/2013 5:08 AM, John Landmesser wrote:
This discussion seems to be finished ( 92 posts ) and i want to make a proposal
as solution:
Use the function DateDiff from Jedi ( RxLib ) ( JvJCLUtils.pas ).
It's not perfect, but it works for me:
in what way do you think it is not perfect for
On 11/16/2013 10:09 AM, waldo kitty wrote:
On 11/16/2013 5:08 AM, John Landmesser wrote:
This discussion seems to be finished ( 92 posts ) and i want to make a proposal
as solution:
Use the function DateDiff from Jedi ( RxLib ) ( JvJCLUtils.pas ).
that routine is actually a procedure... the
On Fri, 15 Nov 2013, Bart wrote:
On 11/15/13, Michael Schnell mschn...@lumino.de wrote:
In fact I consider it a waste of bandwidth to discuss a problem that
obviously is not solvable at this length. (But who am I do complain
about that :-[ .)
Of course it can be solved.
Just add a enough
On 16/11/2013 18:21, Michael Van Canneyt wrote:
On Fri, 15 Nov 2013, Bart wrote:
The fun part for me is the fact that a seemingly simple question,
where at first glance you would think I'll just implement that, can
lead to so many problems.
I added a modified version of your implementation
On Sat, 16 Nov 2013, Reinier Olislagers wrote:
On 16/11/2013 18:21, Michael Van Canneyt wrote:
On Fri, 15 Nov 2013, Bart wrote:
The fun part for me is the fact that a seemingly simple question,
where at first glance you would think I'll just implement that, can
lead to so many problems.
I
On 11/16/2013 11:07 AM, waldo kitty wrote:
[...]
but i still wonder if the last day of a month to the last day of another month
should be counted as a full month...
eg:
CalendarDateDiff: 2012-01-31 to 2012-02-29 =0 yrs0 mos 29 days
JediDateDiff: 2012-01-31 to 2012-02-29 =
On 11/16/2013 12:27 PM, Reinier Olislagers wrote:
On 16/11/2013 18:21, Michael Van Canneyt wrote:
On Fri, 15 Nov 2013, Bart wrote:
The fun part for me is the fact that a seemingly simple question,
where at first glance you would think I'll just implement that, can
lead to so many problems.
I
After all, what would the optimum solution?
Em 16-11-2013 14:40, Michael Van Canneyt escreveu:
On Sat, 16 Nov 2013, Reinier Olislagers wrote:
On 16/11/2013 18:21, Michael Van Canneyt wrote:
On Fri, 15 Nov 2013, Bart wrote:
The fun part for me is the fact that a seemingly simple question,
Am 2013-11-16 16:09, schrieb waldo kitty:
plus, the name should be more in line with the actual process...
CalendarDateDiff or CalendarDiff...
Yes, that sounds good.
It makes it clear that the calculation is different to diff-function that use
average values.
--
On 14/11/13 17:48, Jürgen Hestermann wrote:
Am 2013-11-14 07:56, schrieb Patrick Chevalley:
[...]
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
On 11/14/2013 04:06 PM, Frederic Da Vitoria wrote:
-1
Well, everyone is entitled to his opinions, right, else we would all
be doing C :-)
In fact I consider it a waste of bandwidth to discuss a problem that
obviously is not solvable at this length. (But who am I do complain
about that :-[
On 11/15/13, Michael Schnell mschn...@lumino.de wrote:
In fact I consider it a waste of bandwidth to discuss a problem that
obviously is not solvable at this length. (But who am I do complain
about that :-[ .)
Of course it can be solved.
Just add a enough options (appr. 255?) to the
On Thu, 14 Nov 2013 07:19:56 +0100
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Am 2013-11-13 19:42, schrieb Reimar Grabowski:
1 julian year = 365.25 days of 86400 SI seconds each.
Of course there are lots of other definitions for year but if FPC uses the
julian one the value is
On Thu, 14 Nov 2013 07:56:16 +0100
Patrick Chevalley p...@ap-i.net wrote:
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
On Wed, 13 Nov 2013 20:34:36 +0100
John Landmesser joh...@online.de wrote:
What about Databases like mysql, Oracle, Firebird. I'm shure they have
such a function.
For MySQL:
DATEDIFF(expr1,expr2)
DATEDIFF() returns expr1 – expr2 expressed as a value in days from one
date to the other. expr1
El 14/11/2013 7:56, Patrick Chevalley escribió:
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.
Hello,
I was following
On 14.11.2013 10:50, Reimar Grabowski wrote:
For MySQL:
DATEDIFF(expr1,expr2)
DATEDIFF() returns expr1 – expr2 expressed as a value in days from one
date to the other. expr1 and expr2 are date or date-and-time
expressions. Only the date parts of the values are used in the
calculation.
:)
R.
On 11/14/2013 4:41 AM, Reimar Grabowski wrote:
On Thu, 14 Nov 2013 07:19:56 +0100
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Am 2013-11-13 19:42, schrieb Reimar Grabowski:
1 julian year = 365.25 days of 86400 SI seconds each.
Of course there are lots of other definitions for year
On 11/14/2013 4:50 AM, Reimar Grabowski wrote:
On Wed, 13 Nov 2013 20:34:36 +0100
John Landmesser joh...@online.de wrote:
What about Databases like mysql, Oracle, Firebird. I'm shure they have
such a function.
For MySQL:
DATEDIFF(expr1,expr2)
DATEDIFF() returns expr1 – expr2 expressed as a
On Thu, 14 Nov 2013 13:48:46 +0100
John Landmesser joh...@online.de wrote:
[...]
Our function delivers the age of a person in years, months, days.
What is your diff between 31th Jan and 30 March 2013?
Mattias
--
___
Lazarus mailing list
On 11/14/2013 7:25 AM, José Mejuto wrote:
Maybe I'm completly wrong ?
you are completely right, IMHO... one simply needs to choose their desired base
and level of error that is acceptable for their task's needs...
the initial problem arose because there's no easy way to calc the desired
On 14.11.2013 14:16, Mattias Gaertner wrote:
On Thu, 14 Nov 2013 13:48:46 +0100
John Landmesser joh...@online.de wrote:
[...]
Our function delivers the age of a person in years, months, days.
What is your diff between 31th Jan and 30 March 2013?
Mattias
--
Frankly, this list from time to time ...
Em 14-11-2013 11:10, John Landmesser escreveu:
On 14.11.2013 14:16, Mattias Gaertner wrote:
On Thu, 14 Nov 2013 13:48:46 +0100
John Landmesser joh...@online.de wrote:
[...]
Our function delivers the age of a person in years, months, days.
What is
On 11/14/2013 03:46 PM, Frederic Da Vitoria wrote:
.. and where are we now??
Right in the middle of a very interesting discussion :-)
-1
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 11/14/2013 8:16 AM, Mattias Gaertner wrote:
On Thu, 14 Nov 2013 13:48:46 +0100
John Landmesser joh...@online.de wrote:
[...]
Our function delivers the age of a person in years, months, days.
What is your diff between 31th Jan and 30 March 2013?
the one i am currently testing returns
John Landmesser schrieb:
Hihi, i asked a question about a DateDiff function for FreePascal,
because i wanted to know: how many years, month, days left to work in
Office until my pension begins on 01.08.2018.
What do you consider as *one* year, month etc., fixed (average) values
or calender
2013/11/14 Michael Schnell mschn...@lumino.de
On 11/14/2013 03:46 PM, Frederic Da Vitoria wrote:
.. and where are we now??
Right in the middle of a very interesting discussion :-)
-1
Well, everyone is entitled to his opinions, right, else we would all be
doing C :-)
--
Frederic
2013/11/14 John Landmesser joh...@online.de
Hihi, i asked a question about a DateDiff function for FreePascal, because
i wanted to know: how many years, month, days left to work in Office until
my pension begins on 01.08.2018.
.. and where are we now??
Right in the middle of a very
On 11/14/13, waldo kitty wkitt...@windstream.net wrote:
you are completely right, IMHO... one simply needs to choose their desired
base
and level of error that is acceptable for their task's needs...
It's all about definition.
For me I would think that given today is the last day of a given
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,
On 11/14/2013 12:26 PM, Bart wrote:
On 11/14/13, waldo kitty wkitt...@windstream.net wrote:
you are completely right, IMHO... one simply needs to choose their desired
base and level of error that is acceptable for their task's needs...
It's all about definition.
right... that's what i
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
On 12/11/13 22:52, Bart wrote:
On 11/12/13, waldo kitty wkitt...@windstream.net wrote:
you do not need any of the above if you change
Days := (DaysPerMonth(M1, IsLeapYear(Y2)) - D1) + D2 ;
to
Days := (DaysInAMonth(Y2,M1) - D1) + D2;
I did not know about DaysInAMonth.
I
[snip]
All this, should be planned to use 64 bit Unix Timestamps already ;)
(year 2038 is not that long away)
-L.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 13.11.2013 02:33, waldo kitty wrote:
actually, i have in some cases... let's ask this question and see what
your charts and routines return as the result... assuming your format
is DD.MM....
Date1 := 01.01.2000
Date2 := 01.01.2000
should be 0 (zero), right?
then
Date1 :=
On 11/13/2013 3:53 AM, Lukasz Sokol wrote:
[snip]
All this, should be planned to use 64 bit Unix Timestamps already ;)
(year 2038 is not that long away)
agreed but that is dependent on what TDateTime does since it is built on that
like other existing time and date routines ;)
at one point
On 11/13/2013 5:19 AM, John Landmesser wrote:
On 13.11.2013 02:33, waldo kitty wrote:
actually, i have in some cases... let's ask this question and see what your
charts and routines return as the result... assuming your format is
DD.MM....
Date1 := 01.01.2000
Date2 := 01.01.2000
should
On 13.11.2013 14:02, waldo kitty wrote:
We don't need to invent the wheel again, because others have
solutions for that!
then why does this thread exist? O:)
I'll try to find what the usual way is to handle these problems: c++
Libraries for example?!
i don't know as i do not have
NOTE: subject fixed to indicate the actual topic ;)
On 11/13/2013 6:24 AM, Lex Edmonds wrote:
This is my first post on this mailing list, so please bear with me.
I used to do date calculations like this in the '80s when I was writing Real
Estate software.
On Tue, 12 Nov 2013 20:33:00, waldo
Am 2013-11-13 16:22, schrieb waldo kitty:
A baby born on 1/01/2007 would be 7 days old on 7/01/2007.
true :)
Realy?
That would mean that a baby born on 2007-01-01 10:00
is two days old on 2007-01-02 10:00?
To me this seems wrong because after 24 hours is only one day old.
A simple substraction
On 11/13/2013 9:37 AM, John Landmesser wrote:
On 13.11.2013 14:02, waldo kitty wrote:
We don't need to invent the wheel again, because others have solutions for that!
then why does this thread exist? O:)
I'll try to find what the usual way is to handle these problems: c++ Libraries
for
On Tue, 12 Nov 2013 22:00:39 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
Seeing this, I can't help but think that the approximation approach
may not be such a bad idea after all :D
Can you elaborate what the approximation is? I fail to see it.
1 julian year = 365.25 days of
On 13.11.2013 18:31, waldo kitty wrote:
On 11/13/2013 9:37 AM, John Landmesser wrote:
On 13.11.2013 14:02, waldo kitty wrote:
We don't need to invent the wheel again, because others have
solutions for that!
then why does this thread exist? O:)
I'll try to find what the usual way is to
On Wed, 13 Nov 2013, Reimar Grabowski wrote:
On Tue, 12 Nov 2013 22:00:39 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
Seeing this, I can't help but think that the approximation approach
may not be such a bad idea after all :D
Can you elaborate what the approximation is?
On 11/13/2013 1:42 PM, Reimar Grabowski wrote:
On Tue, 12 Nov 2013 22:00:39 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
Seeing this, I can't help but think that the approximation approach
may not be such a bad idea after all :D
Can you elaborate what the approximation is? I
On 11/13/13, John Landmesser joh...@online.de wrote:
I'm just a hobbyist, never went to university to study computer science.
So am I.
(For my background, see my userpage on the wiki)
We don't need to invent the wheel again, because others have solutions
for that!
Of course we don't have to.
On 13.11.2013 23:14, Bart wrote:
On 11/13/13, John Landmesser joh...@online.de wrote:
I'm just a hobbyist, never went to university to study computer science.
So am I.
(For my background, see my userpage on the wiki)
Found your userpage , read it with great interest.
Your experience with
On 11/13/2013 5:14 PM, Bart wrote:
On 11/13/13, John Landmesser joh...@online.de wrote:
I'm just a hobbyist, never went to university to study computer science.
So am I.
(For my background, see my userpage on the wiki)
i probably should set something, too... while i have an account on the
Hi,
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.
This is actually 365.2422 days, and this is named
Am 2013-11-13 19:42, schrieb Reimar Grabowski:
1 julian year = 365.25 days of 86400 SI seconds each.
Of course there are lots of other definitions for year but if FPC uses the
julian one the value is exact and no approximation
So the difference between 2007-01-01 12:00 and 2008-01-01 12:00
On 11/14/2013 07:19 AM, Jürgen Hestermann wrote:
But this it totaly wrong.
As is defining a meter by the count stretched rubber bands: 1 2, 3, 4 or
5 All numbers are true and all are wrong :-) :-) :-)
-Michael
--
___
Lazarus mailing list
On 11/12/13, Michael Van Canneyt mich...@freepascal.org wrote:
Feel free to provide other functions, I will happily accept them.
I proposed a solution in this thread.
It'll give you (at least that was the intention) the years, months,
and days between two (Gregorian) dates.
Bart
--
2013/11/12 Michael Van Canneyt mich...@freepascal.org
On Tue, 12 Nov 2013, Jürgen Hestermann wrote:
Am 2013-11-11 17:25, schrieb Michael Van Canneyt:
The number of elapsed DAYS between these 2 dates is 60.
If the average number of days per month is assumed to be 30.4375, then 2
full
On 12.11.2013 13:05, Bart wrote:
I proposed a solution in this thread.
It'll give you (at least that was the intention) the years, months,
and days between two (Gregorian) dates.
Bart
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 11/11/2013 6:54 PM, waldo kitty wrote:
On 11/11/2013 10:46 AM, John Landmesser wrote:
Fazit:
You can't write a DateDif function with the functions in DateUtils.pas ?!!
actually, you can but it is more brute-force for the results that you and i are
looking for... brute-force as in actually
*FWIW*
On 11/11/2013 5:11 PM, Bart wrote:
type
TDaysPerMonth = Array[1..12] of Word;
function DaysPerMonth(AMonth: Word; IsLeapYear: Boolean): Word;
const
DaysPerMonthNormal: TDaysPerMonth = (31,28,31,30,31,30,31,31,30,31,30,31);
DaysPerMonthLeap: TDaysPerMonth =
On 12.11.2013 21:01, waldo kitty wrote:
type
Date_Diff = record
Years,
Months,
Days: Word;
end;
function CalendarDateDiff(Date1,Date2: TDateTime): Date_Diff;
var
theDiffRec: Date_Diff;
Cmp: Integer;
loDate,hiDate: TDateTime;
On 12.11.2013 21:40, John Landmesser wrote:
Which is correct?
Date1 := 29.2.2000
Date2 := 28.02.2001
Your function:
0 Y, 11 M, 27 D
Rxlib ( Jedi ) DateDiff:
0 Y, 11 M, 28 D
Libre Office Calc:
0 Y, 11 M, 30 D
The table - function of Libre Office Calc is called in german DATUMDIF()
Get a
On Tue, 12 Nov 2013, John Landmesser wrote:
Date1 := 29.2.2000
Date2 := 28.02.2001
Your function:
0 Y, 11 M, 27 D
Rxlib ( Jedi ) DateDiff:
0 Y, 11 M, 28 D
Libre Office Calc:
0 Y, 11 M, 30 D
The table - function of Libre Office Calc is called in german DATUMDIF()
Get a calendar and
On 11/12/13, John Landmesser joh...@online.de wrote:
On 12.11.2013 21:40, John Landmesser wrote:
Which is correct?
Date1 := 29.2.2000
Date2 := 28.02.2001
I would actually say that in this particular case the diff is 1 Year...
(11 M + (28 days in feb in a non-leapyear = 1M) = 12M = 1 Y.
On 11/12/13, waldo kitty wkitt...@windstream.net wrote:
you do not need any of the above if you change
Days := (DaysPerMonth(M1, IsLeapYear(Y2)) - D1) + D2 ;
to
Days := (DaysInAMonth(Y2,M1) - D1) + D2;
I did not know about DaysInAMonth.
I just went coding and created that
On 11/12/13, John Landmesser joh...@online.de wrote:
On 12.11.2013 21:40, John Landmesser wrote:
Which is correct?
Date1 := 29.2.2000
Date2 := 28.02.2001
Your function:
0 Y, 11 M, 27 D
Rxlib ( Jedi ) DateDiff:
0 Y, 11 M, 28 D
[snip]
RxLib is correct !!!
Fixed. (?)
procedure
On 11/12/2013 3:40 PM, John Landmesser wrote:
On 12.11.2013 21:01, waldo kitty wrote:
[...]
Which is correct?
Date1 := 29.2.2000
Date2 := 28.02.2001
Your function:
0 Y, 11 M, 27 D
Rxlib ( Jedi ) DateDiff:
0 Y, 11 M, 28 D
Libre Office Calc:
0 Y, 11 M, 30 D
The table - function of Libre
On 11/08/2013 09:35 PM, John Landmesser wrote:
Result would be: 0 years, 0 moths, 11 days
IMHO a date diff in this format us desperately misleading, as the count
of days in a month varies.
-Michael
--
___
Lazarus mailing list
On 11/11/2013 3:39 AM, Michael Schnell wrote:
On 11/08/2013 09:35 PM, John Landmesser wrote:
Result would be: 0 years, 0 moths, 11 days
IMHO a date diff in this format us desperately misleading, as the count of days
in a month varies.
understood but it is what many of us want for tasks of
On 11.11.2013 13:31, waldo kitty wrote:
On 11/11/2013 3:39 AM, Michael Schnell wrote:
On 11/08/2013 09:35 PM, John Landmesser wrote:
Result would be: 0 years, 0 moths, 11 days
IMHO a date diff in this format us desperately misleading, as the
count of days
in a month varies.
understood but
That's what i realized until now::
Quote of lhelp:
MonthsBetween returns the number of whole months between ANow and
AThen. This number is an approximation, based on an average number of
days of 30.4375
per month (average over 4 years). This means the fractional part of a
month is dropped.
On Mon, 11 Nov 2013, John Landmesser wrote:
That's what i realized until now::
Quote of lhelp:
MonthsBetween returns the number of whole months between ANow and AThen.
This number is an approximation, based on an average number of days of
30.4375
per month (average over 4 years). This
On 11/11/2013 04:46 PM, John Landmesser wrote:
Giving up and using the Jedi DateDif function.
What is the problem with that-
IMHO such extraordinary functions should be provided by such highly
specialized libraries.
-Michael
--
___
Lazarus
On 11/11/13, Michael Schnell mschn...@lumino.de wrote:
First try at it:
(Only works for correct Gregorian dates).
uses Classes, SysUtils, DateUtils;
type
TDaysPerMonth = Array[1..12] of Word;
function DaysPerMonth(AMonth: Word; IsLeapYear: Boolean): Word;
const
DaysPerMonthNormal:
On 11/11/2013 10:46 AM, John Landmesser wrote:
Fazit:
You can't write a DateDif function with the functions in DateUtils.pas ?!!
actually, you can but it is more brute-force for the results that you and i are
looking for... brute-force as in actually looping thru each unit and
incrementing
Am 2013-11-11 17:25, schrieb Michael Van Canneyt:
The number of elapsed DAYS between these 2 dates is 60.
If the average number of days per month is assumed to be 30.4375, then 2 full
months would be 60.875 days.
That means that 60 days DOES NOT span 2 full months of 30.4375 days: it falls
On Tue, 12 Nov 2013, Jürgen Hestermann wrote:
Am 2013-11-11 17:25, schrieb Michael Van Canneyt:
The number of elapsed DAYS between these 2 dates is 60.
If the average number of days per month is assumed to be 30.4375, then 2
full months would be 60.875 days.
That means that 60 days DOES
Am 2013-11-10 06:57, schrieb Hans-Peter Diettrich:
Jürgen Hestermann schrieb:
Am 2013-11-09 13:43, schrieb Michael Van Canneyt:
So what ? Do an EncodeDate() and you're all set.
That would be a real performance hit (i.e. when sorting by date)
if you have stored dates in year, month, day...
Am 2013-11-08 21:35, schrieb John Landmesser:
i'm searching a pascal datetime function that simulates an Excel function:
DateDif
Excel for example knows the function DateDif that returns the number of
Years, month and days between Date1 and date2.
Date1 := 21.12.2012
Date2 := 01.01.2013
On Fri, 8 Nov 2013, John Landmesser wrote:
Hi List,
i'm searching a pascal datetime function that simulates an Excel function:
DateDif
Excel for example knows the function DateDif that returns the number of
Years, month and days between Date1 and date2.
Date1 := 21.12.2012
Date2 :=
Am 2013-11-09 12:12, schrieb Michael Van Canneyt:
The dateutils unit contains DaysBetween, MinutesBetween, HoursBetween, etc.
Each function exists in 2 variants: one which takes partial times, another
which does complete days/hours/minutes.
See
On 09.11.2013 06:55, leledumbo wrote:
Date1 := EncodeDate(2012,12,21);
Date2 := EncodeDate(2013,01,01);
Your code Result is: 1900 Years, 1 Month, 10 days and thats incorrect.
I thought about it some time and found a solution:
Think of the age of an employe! We have now() and his
On Sat, 9 Nov 2013, Jürgen Hestermann wrote:
Am 2013-11-09 12:12, schrieb Michael Van Canneyt:
The dateutils unit contains DaysBetween, MinutesBetween, HoursBetween, etc.
Each function exists in 2 variants: one which takes partial times, another
which does complete days/hours/minutes.
See
Indeed that was wrong, I shouldn't exploit the internal details. Below is the
correct one (still no need for that complicated code of yours):
uses
SysUtils,DateUtils;
var
Date1,Date2: TDate;
Y,M,D: Word;
begin
Date1 := EncodeDate(2012,12,21);
Date2 := EncodeDate(2013,01,01);
Y
On 11/9/2013 12:55 AM, leledumbo wrote:
uses
SysUtils;
var
Date1,Date2: TDate;
Y,M,D: Word;
begin
Date1 := EncodeDate(2012,12,21);
Date2 := EncodeDate(2013,01,01);
DecodeDate(Date2 - Date1,Y,M,D);
// you have them in Y, M and D, respectively
end.
yeah, that doesn't work...
On 09.11.2013 14:32, leledumbo wrote:
Indeed that was wrong, I shouldn't exploit the internal details. Below is the
correct one (still no need for that complicated code of yours):
uses
SysUtils,DateUtils;
var
Date1,Date2: TDate;
Y,M,D: Word;
begin
Date1 := EncodeDate(2012,12,21);
Am 2013-11-09 13:43, schrieb Michael Van Canneyt:
So what ? Do an EncodeDate() and you're all set.
That would be a real performance hit (i.e. when sorting by date)
if you have stored dates in year, month, day... format.
Each comparison then needs multiple convertions each time.
--
On Sat, 9 Nov 2013, Jürgen Hestermann wrote:
Am 2013-11-09 13:43, schrieb Michael Van Canneyt:
So what ? Do an EncodeDate() and you're all set.
That would be a real performance hit (i.e. when sorting by date)
if you have stored dates in year, month, day... format.
Each comparison then
On 11/9/2013 8:32 AM, leledumbo wrote:
Indeed that was wrong, I shouldn't exploit the internal details. Below is the
correct one (still no need for that complicated code of yours):
uses
SysUtils,DateUtils;
var
Date1,Date2: TDate;
Y,M,D: Word;
begin
Date1 := EncodeDate(2012,12,21);
Am 2013-11-09 16:54, schrieb Michael Van Canneyt:
On Sat, 9 Nov 2013, Jürgen Hestermann wrote:
That would be a real performance hit (i.e. when sorting by date)
if you have stored dates in year, month, day... format.
Each comparison then needs multiple convertions each time.
Not if you store
digging deeper to work directly with YearsBetween and MonthsBetween shows that
they seem to be missing the usual +0.5 generally used to ensure that rounding
is properly handled...
the following two pairs of routines work to give the desired output...
*this pair uses Trunc((X)+.05) instead
Am 2013-11-09 18:42, schrieb waldo kitty:
Result:=Trunc(((Abs(MyDateTimeDiff(ANow,AThen))+TDateTimeEpsilon)/ApproxDaysPerYear)+0.5);
end;
I thought that correct results should be calculated, not only approximate
values.
What is ApproxDaysPerYear?
A leap year has 266 days and others 365 and
1 - 100 of 110 matches
Mail list logo
