2013/11/18 Jürgen Hestermann
>
> Am 2013-11-18 13:11, schrieb Frederic Da Vitoria:
>
> First of all, I decided to use a different name. DateDiff comes from
>> Excel, this is Lazarus, we should try to use names consistent with our
>> functions. I chose DatesToAge, but I am not convinced this name
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
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.
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 immediat
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 immediat
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 immedi
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
--
___
Am 2013-11-18 13:11, schrieb Frederic Da Vitoria:
First of all, I decided to use a different name. DateDiff comes from Excel,
this is Lazarus, we should try to use names consistent with our functions. I
chose DatesToAge, but I am not convinced this name is any better to any other
name which h
Am 2013-11-18 15:44, schrieb Frederic Da Vitoria:
2013/11/18 John Landmesser mailto:joh...@online.de>>
Perhaps it's more "usual" if you change the "out" Parameters to word?
Yes, it would be more usual, but since you seem interested, I will try to create a
"signed version, which will of
2013/11/18 John Landmesser
> 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?
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 Michael Schnell
> 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 this
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
http://lists.lazarus.freepascal.org/mail
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 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".
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,
w
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 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".
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 imp
On Fri, 15 Nov 2013, Bart wrote:
On 11/15/13, Michael Schnell 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
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 o
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 yo
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 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 := 01.0
On 11/15/13, Michael Schnell 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 procedure to make it
be
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 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 repres
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
On 11/14/2013 12:26 PM, Bart wrote:
On 11/14/13, waldo kitty 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 meant by "desired base"... e
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/13, waldo kitty 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
month, then "today"
2013/11/14 John Landmesser
> 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 interesting discuss
2013/11/14 Michael Schnell
> 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 Da Vitoria
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 v
On 11/14/2013 8:16 AM, Mattias Gaertner wrote:
On Thu, 14 Nov 2013 13:48:46 +0100
John Landmesser 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
2013-01-31 to 2
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
http://lists.lazarus.freepasca
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 wrote:
[...]
"Our" function delivers the age of a person in years, months, days.
What is your diff between
On 14.11.2013 14:16, Mattias Gaertner wrote:
On Thu, 14 Nov 2013 13:48:46 +0100
John Landmesser 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
--
___
L
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 out
On Thu, 14 Nov 2013 13:48:46 +0100
John Landmesser 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
Lazarus@lists.lazarus.fre
On 11/14/2013 4:50 AM, Reimar Grabowski wrote:
On Wed, 13 Nov 2013 20:34:36 +0100
John Landmesser 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 fr
On 11/14/2013 4:41 AM, Reimar Grabowski wrote:
On Thu, 14 Nov 2013 07:19:56 +0100
Jürgen Hestermann 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
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.
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 t
On Wed, 13 Nov 2013 20:34:36 +0100
John Landmesser 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 and expr2 are
On Thu, 14 Nov 2013 07:56:16 +0100
Patrick Chevalley 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
> scale.
>
>
On Thu, 14 Nov 2013 07:19:56 +0100
Jürgen Hestermann 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 exact and no approxima
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
Lazar
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
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 the
On 11/13/2013 5:14 PM, Bart wrote:
On 11/13/13, John Landmesser 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 wiki and
have don
On 13.11.2013 23:14, Bart wrote:
On 11/13/13, John Landmesser 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 Lazarus sounds fimil
On 11/13/13, John Landmesser 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.
I just gor in
On 11/13/2013 1:42 PM, Reimar Grabowski wrote:
On Tue, 12 Nov 2013 22:00:39 +0100 (CET)
Michael Van Canneyt 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 juli
On Wed, 13 Nov 2013, Reimar Grabowski wrote:
On Tue, 12 Nov 2013 22:00:39 +0100 (CET)
Michael Van Canneyt 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 jul
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 han
On Tue, 12 Nov 2013 22:00:39 +0100 (CET)
Michael Van Canneyt 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 86400 SI seconds each.
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 exa
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 substracti
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 ki
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 tha
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 b
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 i
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 := 01.01.2000
[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 12/11/13 22:52, Bart wrote:
> On 11/12/13, waldo kitty 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 jus
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 Offi
On 11/12/13, John Landmesser 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. (?)
proced
On 11/12/13, waldo kitty 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 function because I
On 11/12/13, John Landmesser 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.
Bart
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 count?
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 cal
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;
*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 = (31,29,31,30,31,
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
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
2013/11/12 Michael Van Canneyt
>
> 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 wo
On 11/12/13, Michael Van Canneyt 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
--
__
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 NOT
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 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 a
On 11/11/13, Michael Schnell 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: TDaysPerMonth = (31,28,31,
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 mail
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 me
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 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
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 th
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
Lazarus@lists.lazarus.
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... f
waldo kitty schrieb:
DecodeDate(Date2 - Date1,Y,M,D);
// you have them in Y, M and D, respectively
yeah, that doesn't work...
Y = 1900
M = 1
D = 10
Y should be 1 in this case...
I'm not sure, IMO also M and D should be decremented by 1.
ideally, real numbers would be used so that f
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... format.
Each comparison then needs multiple convertion
On 11/9/2013 1:54 PM, Michael Van Canneyt wrote:
On Sat, 9 Nov 2013, Jürgen Hestermann wrote:
If you need to use an approximate value for days in the year then some is
wrong IMO.
Not if it is clearly documented.
actually, in the name of accuracy, it is highly desirable... being able to
dete
On 11/9/2013 1:48 PM, Jürgen Hestermann wrote:
Am 2013-11-09 18:31, schrieb Michael Van Canneyt:
> On Sat, 9 Nov 2013, Jürgen Hestermann wrote:
>> Storing dates as floats has a lot of drawbacks.
>> It's inaccurate, you always need a starting date and get other problems.
> Can you prove this s
On 11/9/2013 1:41 PM, Michael Van Canneyt wrote:
On Sat, 9 Nov 2013, waldo kitty wrote:
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...
You misunderstood th
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 := 01.0
On 11/9/2013 12:59 PM, Jürgen Hestermann wrote:
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 "ApproxDay
>if you have stored dates in year, month, day... format.
>Each comparison then needs multiple convertions each time.
nonsense.
Store it as packed record word-byte-byte = int and you have faster
comparisons than TDateTime!
On 11/09/2013 04:23 PM, Jürgen Hestermann wrote:
Am 2013-11-09 13:43,
On Sat, 9 Nov 2013, Jürgen Hestermann wrote:
Am 2013-11-09 18:31, schrieb Michael Van Canneyt:
On Sat, 9 Nov 2013, Jürgen Hestermann wrote:
Storing dates as floats has a lot of drawbacks.
It's inaccurate, you always need a starting date and get other problems.
Can you prove this statement ?
Am 2013-11-09 18:31, schrieb Michael Van Canneyt:
> On Sat, 9 Nov 2013, Jürgen Hestermann wrote:
>> Storing dates as floats has a lot of drawbacks.
>> It's inaccurate, you always need a starting date and get other problems.
> Can you prove this statement ?
Well, aren't the current mails about inc
On Sat, 9 Nov 2013, waldo kitty wrote:
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...
You misunderstood these functions.
There is no rounding necessary.
1 - 100 of 118 matches
Mail list logo
