sort dateTime problem
gandalf at doctorTimothyMiller.com
Thu Dec 15 20:55:39 CST 2005
>From: Jim Ault <JimAultWins at ...>
>Subject: Re: sort dateTime problem
>Date: 2005-12-15 04:48:31 GMT (20 hours and 30 minutes ago)
>sort lines of cd field "schedule.2" datetime by item 2 of each
>What is the itemDel set to just before this step?
>Are there any delimiters in what seems to be item 1?
>Is there any reason the short date is not valid?
>(eg 13/4/04 does not exist)
>On 12/14/05 4:53 PM, "Timothy Miller" <gandalf at ...>
>> One line of a script I'm working on goes:
>> sort lines of cd field "schedule.2" datetime by item 2 of each.
>> Each line has four items. Item 2 consists of dates in short date
>> format, e.g., 12/2/04.
>> All 2005 dates come up in correct sequence, from earliest to latest.
>> However, after sorting, 2004 dates *follow* 2005 dates, instead of
>> preceding them. That is not a correct sort.
>> Am I doing something wrong?
Hey, Jim, thanks.
If it works on your machine, I suppose I'm doing something wrong. Hmmm...
I just did quite a bit of haphazard troubleshooting. I isolated the
problem. The short dates are all preceded by a spacebar character. If
I remove the spacebar characters, the sort works correctly. This is
easily reproduced. It doesn't seem to matter whether items, lines or
words are being sorted.
I don't know about dates or times in other formats. I don't know
about more than one spacebar character. I didn't check.
Further testing shows that, in the problem script, converting a short
date to seconds, if the short date is preceded by a spacebar
character, produces a negative number. If the original date is in
year 2005, the negative seconds covert back to a date in 1950 or so.
If I use a simple script in button or msg box, then converting
"4/19/05" to seconds produces the same value as converting
"<spacebar>4/19/05" to seconds.
OTOH, if a script with a repeat loop converts several words, items,
or lines, one at a time, from short date to seconds, a leading
spacebar character in the short date produces incorrect results.
That doesn't seem right, does it? Okay, I'll reproduce it more
carefully, just to be sure.
Yup, I reproduced it.
This seems like a flaw in the way Rev interprets certain dates, under
More information about the use-livecode