a little more on datetime

Timothy Miller gandalf at doctorTimothyMiller.com
Mon Dec 19 16:28:42 EST 2005


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" <gandalf at doctorTimothyMiller.com>
>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" <gandalf at doctorTimothyMiller.com>
>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 at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your 
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list