How to know whether a dateItem is before or after another?

[Mag]

Naturally this don't work...

Code: Select all

   convert date1 to dateItems
   convert date2 to dateItems

   if date2 > date1 then
      answer "date1 is before than date2"
   end if

[bangkok]

Convert your 2 dates... in seconds.

And then you can compare.

[dunbarx]

Hi.

What Bangkok said.

But this works as well:

Code: Select all

on mouseUp
   put "5/9/94"  into d1
   put "5/9/95"  into d2
   
    convert d1 to dateItems
      convert d2 to dateItems
   
      if d2 > d1 then answer "date1 is before date2"
   else answer "date2 is before date1"
end mouseUp

What did not for you?

Craig Newman

[Mag]

Thank you for your post bangkok.

Hi Craig, I realized that I was doing the conversion in the wrong place. Thank you.

Can I then make a date converted to dateitems, to seconds with convert command or it's necessary to construct the date using items?

[Mag]

I done some more tests and I'm not sure that when you compare dateItems, it compares dates, maybe it compares something else, so:

2014,4,16,10,3,15,4 < 2014,4,16,9,34,50,4

[Klaus]

What exactly would you exspect when you try to compare 2 STRINGS instead of two (single) numbers?
...
put ("Klaus" < "Mag")
## -> TRUE
## Whatever that means
...

[dunbarx]

Hi.

What exactly would you expect when you try to compare 2 STRINGS instead of two (single) numbers?

Did you get what Klaus meant? (And what I said?) He makes a very important point.

It is almost a kluge that dateItems can be compared this way. The order of items: year,month,day,24 hour time, etc, allows the string comparison to work in a date comparison way. All because the order of items in that keyword makes sense in an ever-decreasing series of values that refine an instant of time. This may actually have been done on purpose, back in 1987.

The one item in that string that might throw a monkey wrench into the mix is the last item, the day-of-week. But that last item will never be counted, since earlier ones will already have made their "choice".

Craig

[FourthWorld]

In addition to easy comparison, another benefit to storing time stamps as seconds is that they're independent of time zones, being the number of seconds elapsed since Jan 1 1970 GMT.

So when doing conversions to human-readable formats, the output represents the time in a form appropriate for the local machine. This can be very valuable for groupware applications where team members may be in different time zones.

The only human-readable date/time format that's time-zone-independent in LC is internet date, e.g.:

Wed, 16 Apr 2014 06:42:02 -0700

Conversions on internet date format will also be presented in local time, thanks to the GMT offset it includes. But of course since that string begins with the week day it's not a good choice for comparison, and if you have a lot of data the more compact form of seconds will save a little space as well.

[Mag]

Thank you guys, because of the possibility of make date calculations with dateItems, I was erroneous think that that variable it had some magical status.

Code: Select all

on mouseUp
   convert the date to dateItems
   put it into field 1 -- 2014,4,16,0,0,0,4
   add 23 to item 3 of it
   put it into field 2 -- 2014,4,39,0,0,0,4
   convert it to date
   put it into field 3 -- 5/9/14
end mouseUp

Ah, what a fool I've been, nothing works in this way in RevTalk (By the way, this is correct definition of the language?). As noted by Klaus, a string is just a string... Now I understand that the magic is due by the nature of the convert command, and not by some special property of the dateItem-generated strings (thank you Klaus )

As suggested by FourthWorld, I will go just with (clear, simple, comparable, beautiful) seconds!

PS
I Craig, I think I misunderstood your code, above, on the comparison, sorry for the confusion