0

I have a query that displays hotel guests stay data (START_DATE,END_DATE). I would like a label to display how many days passed since guests last visit relative to today. So,example, if guest left on the 29.3.2013 and I view the data, I would like the label to tell me : Last visit "2" days ago.

user763539
  • 3,509
  • 6
  • 44
  • 103

1 Answers1

4

DaysBetween works here, too, just like it works in your last question. 

Label1.Caption := Format('Last visit %d days ago', 
                    [DaysBetween(Date, Qry.FieldByName('END_Date').AsDateTime)]);
Ken White
  • 123,280
  • 14
  • 225
  • 444
  • Except, maybe, that the time-of-day probably is irrelevant, so there should be an INT(...) around the "Date" and the "Qry.Field..." parts. – HeartWare Apr 01 '13 at 05:07
  • TDateTime = Extended (or Real, do not remember) where Integer part of the value is count of days after 1900 year (or something) So Trunk(Date2) - Trunk(Date1) = count of days. It is equal to DaysBetween function, but it is 2 times faster (no stack operations and function callings) – Abelisto Apr 01 '13 at 07:08
  • @KenWhite Fractional part is a count of milliseconds of the date. So take in mind round of values. – Abelisto Apr 01 '13 at 07:27
  • 1
    @Abelisto Two times faster?! So what. Why sacrifice readability and expression? Or do you really believe this function call is the perf bottleneck? – David Heffernan Apr 01 '13 at 07:27
  • @DavidHeffernan "push push pop pop ret" at least. Sorry my knowledge about assembler is outdated. In the case of one million of repeating it will be significant. Question just to you: why M$ studio starts in 5 minutes? – Abelisto Apr 01 '13 at 07:36
  • @Abelisto Not really. There's a database query here. That swamps a procedure call. If you believe what you say, then write all your code in asm and never call functions. Put everything inline. Do you do that? No, I didn't think so. – David Heffernan Apr 01 '13 at 07:46
  • @DavidHeffernan I not "Put everything inline." But I always think about efficiency of code. For example: if i have 2 cases i prefer one which faster. There are a lot of coders who is not remember about that. And because we have "fat" and "slow" programs. – Abelisto Apr 01 '13 at 07:55
  • 3
    @Abelisto Your manifesto leads to hard to maintain programs that are more likely to have defects. Don't just blithely write low level code inline. Only make perf. changes when you have timed and know it makes a real difference. And if you had to do this, write your own DaysBetween function and inline it. So that the code is readable and fast. Suggesting these things in a comment like that is dangerous and irresponsible. I repeat, there is a db query here. Do you even have the faintest idea how many clocks that involves? – David Heffernan Apr 01 '13 at 07:59
  • 1
    @Abelisto Let's hope user has enough sense to ignore it then – David Heffernan Apr 01 '13 at 08:18
  • 2
    @Abelisto Anyway, one of the reasons your version of `DaysBetween` is faster is that it performs a completely different calculation! – David Heffernan Apr 01 '13 at 08:55
  • 2
    There doesn't need to be an `Int` or a `Trunc` around either of the values. I used `Format` with a `%d` specifier, which formats as an integer. Further, the `Format` (or a `FloatToStr`) takes far more overhead than using `DateBetween`, and there's no need for premature optimization here. And Abelisto, please feel free to post your own answer with highly optimized hand written assembly and a benchmark to provide it's signficiantly faster (on your own blog, of course). If you haven't done that, you shouldn't be commenting on efficiency when it's meaningless. – Ken White Apr 01 '13 at 10:58
  • @KenWhite The formatting is not the issue. I guess is meant is that if both of the two date times being compared have non-zero time part then that could cause ambiguity. But since you used `Date`, then there's no problem at all. – David Heffernan Apr 01 '13 at 14:25
  • 3
    @Abelisto - good developers care about performance, but they also know _when_ to worry about such things. Optimizing away a function like `DaysBetween` and replacing with some quick math calc in the name of performance is just not a smart move. Performance optimization needs to be an informed decision, using good profiling techniques, and not "just because." (And need to be tested; your quick calc is not correct because it may return negative values.) – Leonardo Herrera Apr 01 '13 at 15:50
  • @LeonardoHerrera And again: it was not answer but comment. I think programmer must know what is stored in the variable phisicaly. My info may be useful for somebody who want to know it. – Abelisto Apr 01 '13 at 17:56
  • 1
    @Abelisto - the reason you find so much resistance to what you wrote it's not because of technical merits, but common sense. It's plain bad advice, and I would urge to all novice programmers to ignore it. – Leonardo Herrera Apr 01 '13 at 18:08
  • @LeonardoHerrera I would urge to all novice programmers to start those career not from Pascal and even not from assembler but from binary code :) Just for example: after some changes in my real program it was works about several seconds instead of several minutes. But, yes, it becomes to some hardly reading. It is only your choice what is important. – Abelisto Apr 01 '13 at 18:23
  • 1
    @Abelisto That's silly. I'm teaching 10 year olds at a school how to program. You think I should teach them machine code? – David Heffernan Apr 02 '13 at 06:31
  • I think a bracket is missing .AsDateTime)]);,or no ? Problem is that I have multiple dates and the mentioned code picks only the first date that it encounters in the grid (I have placed the above code on the afterscroll of the query). How am I to get the latest date and then show the day difference ? – user763539 Apr 03 '13 at 05:17
  • I think I must have the query stop/select latest date in the grid. – user763539 Apr 03 '13 at 05:24
  • @user763539: I fixed the missing `)`. If you have a different question now, please post it as one. This one was specifically about how many days between two dates. You can always link back from the new one to this one for context. :-) – Ken White Apr 03 '13 at 10:58