sorting by date senile?

Mark Waddingham 36degrees at runrev.com
Wed Mar 9 11:53:09 EST 2005


Hi Xavier,

> Thanks but that is rather arcane! I thought this was a modern tool ;)

Perhaps a little arcane - Revolution currently relies on the underlying
OS for it's date conversion routines - which means time started at
midnight on 01/01/1970 for the most part.

> Would using internet time or the dateitems format work better?

The internet date, while ideal for transmitting dates (as you can also
encode the time-zone), is not really suitable for sorting as it is
designed to be human readable, more than machine processable.

dateItems can be used to sort, but you'd need to sort by each item in
turn:
  put <list of dateItems> into tList
  repeat with n = 1 to 7
    sort lines of tList ascending numeric by item n of each
  end repeat

(the stability of Transcript's sort means that this works fine)

Of course by encoding your dates in the form:
  YYYY/MM/DD
You can just use a string sort. Similarly:
  YYYY/MM/DD HH:MM:SS
Can be sorted using a string sort too.

(the separators used in these cases is irrelevant, as long as it is
consistent)

> repeat with x = 1 to the number of lines in histo 
>    convert (item 1 of line x of histo) to dateitems
> Result = nothing! convert puts the conversion into it! ;((

This is (relatively) consistent with other commands. The 'convert'
command expects a container as its first argument - and if one is not
supplied it will use the default container: it.

In your above syntax you have forced Revolution to evaluate the
container expression as a string by using parantheses. If you were to
do:
  convert item 1 of line x of histo to dateItems
It would do the conversion in place.

> a little fix for this second weird thing!
> 
> Date items now doesn't convert anything before the year 1970!
> 
> Not in the docs either! Or did I miss that? Not in the limits either!
> I added a webnote to the rev docs and I guess this means a dozen
> new functions in XOS to handles these correctly!
> 
> Since I suppose this wont work with the "seconds" for a "simple" numeric
> sort, we now have to resort to 3 sorts, one for each date item!
> Triple the inneficiency here! 6X if you use the time as a factor! ;)

There is no trouble sorting the seconds numerically - but remember, the
seconds counts the number of seconds since 1970 :o)

> >You will have to do some math, but you are good at that ;-)
> 
> Im good at math - but I hate to do it for a system / person
> that is supposed to do it better and faster than me!
> 
> I tried the usesystemdate but it didn't help.

Setting the useSystemDate property causes the date and the time to
format their result using the current system locale as opposed to US
standard formats.

> I dont dare use the centurycutoff as it makes things even more confusing!
> Where does the century start and stop now? 

The centuryCutOff property is only relevant when considering dates with
two digits and determines where the current century ends. If the two
digit year <= centuryCutOff, then it is assumed that it maps to a year
in the current century, else it assumes it maps to a year in the
previous century.

e.g. We are in 2005, setting centuryCutOff to 20 will result in:
  01/01/15 => 01/01/2015
  01/01/25 => 01/01/1925

Hope this clarifies a few things,

Warmest Regards,

Mark.

------------------------------------------------------------------
 Mark Waddingham ~ 36degrees at runrev.com ~ http://www.runrev.com
       Runtime Revolution ~ User-Centric Development Tools



More information about the use-livecode mailing list