Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 10 total
Thread Adding days with date
Tue, Oct 7 2014 8:56 AMPermanent Link

Ronald

Hi,

I am trying to add 7 day to a date with this function:

function IncDay(aValue: DateTime;aNumberOfDays:integer=1):DateTime;
begin
Result:=aValue;
if aNumberOfDays>0 then Result:=aValue+(aNumberOfDays*86400000);
//86400000=MillSecDay;
end;

That does not always work correct. If I try today (10/7/2014) and try to
increment add 21 days it gives me "10/27/2014 11:00 PM". Here I miss an
hour?

What is happening here?

Greetings,
Ronald
Tue, Oct 7 2014 9:33 AMPermanent Link

D.C.

Hi Ronald,
Try this

Result := EncodeDateTime(YearOf(aValue),MonthOf(aValue),DayOf(aValue),0,0,0,0)+(aNumberOfDays*86400000);

To neutralize the hour component of the date. Besides, EncodeDate, EncodeDateTime and other date functions have an optional parameter UTC (boolean) that is false by default. This also help to do the correct math.

Regards,
Diego
Tue, Oct 7 2014 3:16 PMPermanent Link

Ronald

Thanks, Diego, I tested it, but the results are exactly the same.

"D.C." schreef in bericht
news:BBEF7530-5FE6-468E-A4FD-49DE79BE2EA9@news.elevatesoft.com...

Hi Ronald,
Try this

Result :=
EncodeDateTime(YearOf(aValue),MonthOf(aValue),DayOf(aValue),0,0,0,0)+(aNumberOfDays*86400000);

To neutralize the hour component of the date. Besides, EncodeDate,
EncodeDateTime and other date functions have an optional parameter UTC
(boolean) that is false by default. This also help to do the correct math.

Regards,
Diego
Tue, Oct 7 2014 4:40 PMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 10/7/2014 8:56 AM, Ronald wrote:
> I am trying to add 7 day to a date with this function:
> That does not always work correct. If I try today (10/7/2014) and try to
> increment add 21 days it gives me "10/27/2014 11:00 PM". Here I miss an
> hour?
>
> What is happening here?

It looks like a daylight savings time change.

I ran a quick test and in my case in early Nov it jumps back an hour and
march it jumps an hour forward in terms of the time portion.

Technically this is correct behavior - i.e. if you were to schedule
something after DST change then time EWB calculates is accurate.

Best bet for you might be to calculate the date separately (i.e. using
encodetime or such) and then just add the time portion as needed.

Raul
Wed, Oct 8 2014 3:12 AMPermanent Link

Ronald

Yes, you could be exactly right. But why does it subtract the
daylightsavings hour? I only calculate the days, it should "ignore" hours,
seconds etc. That is a problem of course since the calculations are based
the number of milliseconds since midnight on January 1, 1970. Are there any
functions possible that can add a number of days not based on the amount of
milliseconds?

"Raul"  schreef in bericht
news:023AB80D-9FCF-4D65-9E0F-1F3D43151A48@news.elevatesoft.com...

On 10/7/2014 8:56 AM, Ronald wrote:
> I am trying to add 7 day to a date with this function:
> That does not always work correct. If I try today (10/7/2014) and try to
> increment add 21 days it gives me "10/27/2014 11:00 PM". Here I miss an
> hour?
>
> What is happening here?

It looks like a daylight savings time change.

I ran a quick test and in my case in early Nov it jumps back an hour and
march it jumps an hour forward in terms of the time portion.

Technically this is correct behavior - i.e. if you were to schedule
something after DST change then time EWB calculates is accurate.

Best bet for you might be to calculate the date separately (i.e. using
encodetime or such) and then just add the time portion as needed.

Raul
Wed, Oct 8 2014 3:51 AMPermanent Link

Matthew Jones

Ronald wrote:

> Yes, you could be exactly right. But why does it subtract the
> daylightsavings hour? I only calculate the days, it should "ignore"
> hours, seconds etc. That is a problem of course since the
> calculations are based the number of milliseconds since midnight on
> January 1, 1970. Are there any functions possible that can add a
> number of days not based on the amount of milliseconds?

I started with a simple response and then the logic all fell over. Time
code is never simple. The key will be to separate the date part from
any time part. And then to work out a way to move a date forward N days
while watching for a change in DST flag. I am working on a codebase at
the moment which, due to a bug in Visual C++ 6, has the base time as
PST, but is used around the world, so it has to take account of the
offset to local, but then also of a few weeks where PST goes to DST
differently to the local timezone. It is horrible.

I'm sort ot tempted to suggest that the best hack would be to add the
86400000 for the days, then two of 28800 (an hour, I think) to push you
to the proper day you were wanting at at least 1am. (Subtract if going
back in time.) Then get the date from that into integers, and then
encode those integers into a date again, which gets you the proper
midnight value at that date.

But if you can think of a better way, please use it...


Matthew Jones
Wed, Oct 8 2014 5:35 AMPermanent Link

Ronald

If I add  up all suggestions, I come to this function which seems to work
correct:

function IncDay(aValue: DateTime;aNumberOfDays:integer=1):DateTime;
var
MillSecDay  :integer=86400000;
MillSecHour :integer=3600000;
begin
Result:=EncodeDateTime(YearOf(aValue),MonthOf(aValue),DayOf(aValue),0,0,0,0)+(aNumberOfDays*MillSecDay)+(2*MillSecHour);
Result:=EncodeDateTime(YearOf(Result),MonthOf(Result),DayOf(Result),0,0,0,0);
end;

The vars MillSecDay and MillSecHour are only local for this example.


"Matthew Jones"  schreef in bericht
news:AEA9B556-2993-459A-8327-0CF506FCF436@news.elevatesoft.com...

Ronald wrote:

> Yes, you could be exactly right. But why does it subtract the
> daylightsavings hour? I only calculate the days, it should "ignore"
> hours, seconds etc. That is a problem of course since the
> calculations are based the number of milliseconds since midnight on
> January 1, 1970. Are there any functions possible that can add a
> number of days not based on the amount of milliseconds?

I started with a simple response and then the logic all fell over. Time
code is never simple. The key will be to separate the date part from
any time part. And then to work out a way to move a date forward N days
while watching for a change in DST flag. I am working on a codebase at
the moment which, due to a bug in Visual C++ 6, has the base time as
PST, but is used around the world, so it has to take account of the
offset to local, but then also of a few weeks where PST goes to DST
differently to the local timezone. It is horrible.

I'm sort ot tempted to suggest that the best hack would be to add the
86400000 for the days, then two of 28800 (an hour, I think) to push you
to the proper day you were wanting at at least 1am. (Subtract if going
back in time.) Then get the date from that into integers, and then
encode those integers into a date again, which gets you the proper
midnight value at that date.

But if you can think of a better way, please use it...


Matthew Jones
Wed, Oct 8 2014 6:40 AMPermanent Link

Matthew Jones

Ronald wrote:

> +(2*MillSecHour)

With the provison that this only works as-is for future dates. If you
are going back in time, you'd need to subtract this (or multiply
something by the increment value to get negative).

--

Matthew Jones
Wed, Oct 8 2014 8:55 AMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 10/8/2014 3:12 AM, Ronald wrote:
> Yes, you could be exactly right. But why does it subtract the
> daylightsavings hour? I only calculate the days, it should "ignore"
> hours, seconds etc. That is a problem of course since the calculations
> are based the number of milliseconds since midnight on January 1, 1970.

Like you said it's milliseconds so technically we're not working with
days at all - just adding milliseconds which should "behave the same
whether you're adding days, minutes,seconds or hours worth of value.

What should happen on daylight change night at 1am if i were to add 1
hour ? Technically it should be back at 1am so yes it's complex and i
hope EWB address this in the framework once initial 2.x release is out
with some additional functions.

Looks like you got a formula already that works though.

My suggestion would have been something like this - it basically
re-encodes the date part only and then uses 10am for time (this is just
to ensure we don't change date part if we cross daylight change).

Then it re-encodes the result using the new date and original time.

Have not tested much but should forward and backward (i.e. negative days)

function incDays(dt:DateTime;aNumDays:integer=1):DateTime;
var
   dtTemp:DateTime;
begin
   dtTemp := EncodeDateTime( YearOf(dt),Monthof(dt),DayOf(dt),10,0,0,0);
   dtTemp := dtTemp + (aNumDays * 86400000);
   result := EncodeDateTime(
YearOf(dtTemp),Monthof(dtTemp),DayOf(dtTemp),HourOf(dt),MinuteOf(dt),SecondOf(dt),MSecondOf(dt));
end;




Raul


Wed, Oct 8 2014 9:37 AMPermanent Link

Ronald

You are right, these are better:


var
MillSecDay  :integer=86400000;
MillSecHour :integer=3600000;


function IncDay(const aValue: DateTime;aNumberOfDays:integer=1):DateTime;
begin
Result:=aValue;
if aNumberOfDays>0 then
  begin
  Result:=EncodeDateTime(YearOf(aValue),MonthOf(aValue),DayOf(aValue),0,0,0,0)+((aNumberOfDays*MillSecDay)+(2*MillSecHour));
  Result:=EncodeDateTime(YearOf(Result),MonthOf(Result),DayOf(Result),0,0,0,0);
  end;
end;


function DecDay(const aValue: DateTime;aNumberOfDays:integer=1):DateTime;
begin
Result:=aValue;
if aNumberOfDays>0 then
  begin
  Result:=EncodeDateTime(YearOf(aValue),MonthOf(aValue),DayOf(aValue),0,0,0,0)-((aNumberOfDays*MillSecDay)-(2*MillSecHour));
  Result:=EncodeDateTime(YearOf(Result),MonthOf(Result),DayOf(Result),0,0,0,0);
  end;
end;


"Matthew Jones"  schreef in bericht
news:DAFB962A-607E-4927-BD24-CA11A547B054@news.elevatesoft.com...

Ronald wrote:

> +(2*MillSecHour)

With the provison that this only works as-is for future dates. If you
are going back in time, you'd need to subtract this (or multiply
something by the increment value to get negative).

--

Matthew Jones
Image