Login ProductsSalesSupportDownloadsAbout |

Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |

View Thread

The following is the text of the current message along with any replies.

Messages 1 to 10 of 10 total |

Adding days with date |

Tue, Oct 7 2014 8:56 AM | Permanent 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 AM | Permanent 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 PM | Permanent 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 PM | Permanent Link |

Raul Globestar Systems 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 AM | Permanent 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 AM | Permanent 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 AM | Permanent 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 AM | Permanent 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 AM | Permanent Link |

Raul Globestar Systems 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 AM | Permanent 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 |

This web page was last updated on Friday, December 2, 2022 at 07:49 PM | Privacy PolicySite Map © 2022 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |