Hello Jim,
I appreciate your efforts, but I don't think you understood my concern.
I was thinking about a few small changes that might make RR slightly
more user friendly. I've learned by trial and error -- and with the
help of the list -- to anticipate that the IDE might interpret,
convert and sort dates and/or times inconsistently. In the same way,
I've learned to pay close attention to how dates and times are
formatted in my scripts, before I try manipulate them. I've learned
how to write code that will clean up badly formatted dates and times.
Rev gives me the tools to do these jobs in several different ways.
I'm not thinking of me. I'm thinking of a new user not yet convinced
that Rev is the answer to his/her needs. Few new users are going to
come to the table with your degree of expertise or interest.
I think you also misunderstood my reason for looking at the result in
the short scripts I posted. I wanted to know if RR reports a result
if it attempts to interpret a badly formatted date, or a non-date. It
doesn't. It doesn't report a result when attempting to interpret a
value that does not even slightly resemble a date or time. None of
this is documented, as far as I can tell. If it isn't, it should be.
Ideally, future users might be able to skip some of my trial and
error experience. For instance, if the IDE reports that var1 is a
date and then converts or sorts it as if it is not a date, because it
is badly formatted, without reporting an error or result, then RR is
putting the user in a bad position. This seems avoidable. I merely
meant to suggest a small improvement.
I asked if my suggestion is is a bad idea. Is it?
Cheers,
Tim
On 12/18/05 5:29 PM, "Timothy Miller" <[EMAIL PROTECTED]>
wrote: <excerpted>
As Jacque recently mentioned, RR is inconsistent in the way it copes
with dates and times, when interpreting, sorting or converting
values. How true!
The IDE seems to be making these determinations anyway, but not reporting
them
<major snip> (the full quote below)
Caution: You are making assumptions about what 'convert' is working with
for a short date string. As with any programming language, functions are
designed with limitations and tend to be 'GIGO' ( garbage in....). In
particular, date and time functions in any program I have ever worked with
are an adventure in hitting sweet spots, and, boy, are they all different!
Try the following script and see what the nuances are. Pay attention to
what Rev generates as the short date, and then the converted values.
The final answer is that Rev gives you the tools to generate a
"cleanShortDate()" function to hand off to 'convert', much like the 'trim'
functions discussed over the last few weeks.
By the way... you used...
The result is still empty.
What you need ---> look in "it", not the result (according to the docs and
my example)
------------- code to copy starts here
on mousedoubleUp
put " 11/24/96" into var1
answer (var1 is a date) &cr& "var1 could be a date of some sort."
convert var1 to long date
--convert var1 to seconds
answer var1 &cr&" convert var1 to long date = " & it &", Rev did it"
answer var1 &cr&" convert var1 to long date = " & it \
&cr& "whooops.. now why did that happen?? " &cr& "11/24/96 > Dec 31st ?"
convert var1 to short date
answer var1 &cr&" convert var1 to short date = " & it &", Rev did it"
&cr&"Yuk"
convert var1 to seconds
answer var1 &cr& " convert var1 to seconds = " & it &", Rev did it"
&cr&"Double Yuk"
convert "11/24/96" to seconds
answer "11/24/96 >" & it &cr&"starting clean"
convert "11/24/9" to seconds
answer "11/24/9 >" & it &cr&"one char shorter"
convert "11/24/" to seconds
answer "11/24/ >" & it &cr&"two chars shorter gets worse, but there is a
pattern"
--considering short date -- prefix padded with spaces
put "11/24/96" into var2
put "" into resultList
put var2 into original
repeat with x = 1 to 10
put " " before var2
get var2
convert it to short date
put x & "-space prefix [date]= " & it into line x of resultList
end repeat
convert original to short date
put "0-space prefix [date]= " & original &cr before resultList
put cr & "**watch the *year* on each line" after resultList
answer resultList
--considering seconds -- prefix padded with spaces
put "11/24/96" into var3
put "" into resultList
put var3 into original
repeat with x = 1 to 10
put " " before var3
get var3
convert it to seconds
put x & "-space prefix [secs]= " & it into line x of resultList
end repeat
convert original to seconds
put "0-space prefix [secs]= " & original &cr before resultList
answer resultList
--considering a suffix padded with spaces
put "11/24/96" into var4
put "" into resultList
repeat with x = 1 to 10
put " " after var4
get var4
convert it to seconds
put x & "-space suffix = " & it into line x of resultList
end repeat
answer resultList
answer "Moral: At first, First dates can be deceiving"
end mousedoubleUp
---------------- end code to copy
On 12/18/05 5:29 PM, "Timothy Miller" <[EMAIL PROTECTED]>
wrote:
Greetings,
As Jacque recently mentioned, RR is inconsistent in the way it copes
with dates and times, when interpreting, sorting or converting
values. How true!
As far as I can tell, the IDE will appear to sort datetime or convert
from one dateTime format to another, without producing an error
message, regardless of the value in question. It will do so in cases
where the value is almost, but not quite completely unlike a date or
a time. If the IDE cannot understand the value as a date or time, it
sorts as if the value were alphanumeric, or ignores the convert
command.
In addition, it will report a value is a date, but then refuse to
recognize the same value as a date when converting or sorting.
Try this:
on mouseUp
put " 11/24/96" into var1
answer (var1 is a date)
convert var1 to seconds
answer the result
answer var1
end mouseUp
At least on my machine and version, the IDE reports the value is a
date, but then refuses to convert it, or converts it incorrectly. The
result is empty.
This example even stranger:
on mouseUp
put " 11/24/96" & cr & "avfdt" into var1
answer (var1 is a date)
convert var1 to seconds
answer the result
answer var1
end mouseUp
The IDE says the value in the second example is also a number, but it
ignores the same leading spaces AND the second line, AND correctly
converts the first line, leading spaces and all, to seconds! The
result is still empty.
The second example suggests a handy hack if you want to force the IDE
to correctly interpret certain badly formatted dates or times. Just
ad a cr and some nonsense characters in the second line. I'm mostly
joking...
Maybe this is all as it must be, for obscure reasons. Still, it seems
to me the user needs a break here. A small and likely easy step would
be for the IDE to give the user a result, if the user cares to take
advantage of it. "Ambiguous dateTime value" other such words might be
helpful in some cases. "Value not in dateTime format" and "value
contains multiple lines" are other possibilities.
The IDE seems to be making these determinations anyway, but not reporting
them.
Is this is a bad idea?
Tim
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
