extremely weird and frustrating...

[Ben Rubinstein]

I think the point is that (since the new "guessProgrammerIntent" feature that 
Devin spotted yesterday is no longer available today) the code for 
interpreting as "dateTime" has to make assumptions when the data isn't explicit.

Not unreasonably, asked to interpret dd:dd as a datetime value, the code 
guesses that it is HH:MM rather than guessing that it is MM:SS.   Whereas 
asked to interpret dd:dd:dd it will definitely interpret that as HH:MM:SS.

So I wouldn't agree that
 > What you proposed is a workaround because dateTime does NOT work
 > properly, right?

At worst you could say that the implementer, forced to make a decision about 
how to interpret an ambiguous input, made the wrong call (interpret it as 
HH:MM rather than as MM:SS) - but I think it's a judgement call, neither would 
really be wrong or right, just which is likely to be most useful in most cases.

(Of course it's also worth noting that the way sort works is to apply the 
sorting function to pairs of input.  The dateTime evaluation is applied to 
each piece of data in turn - there's no overall evaluation.  An intelligent 
human operator, asked to sort a dozen items, might start interpreting them as 
HH:MM, then come across an instance which couldn't validly be interpreted as 
HH:MM but could be as MM:SS, and therefore decide to start over, now treating 
everything as MM:SS.  But what we have is a machine, implementing a relatively 
efficient and flexible mechanism - which rightly precludes behaviour like that.)

Ben


On 02/04/2014 09:25, larry at significantplanet.org wrote:
> Thanks John,
> I'm not trying to be "cheeky" but I am frustrated.  Sorry Alex.
>
> John, what you propose may work - haven't tried it yet.
> However, that still does not explain why WITHOUT the 0 in front of it, 9:14
> was listed before 11:35 in my ascending sort. And just FYI, those are minutes
> and seconds I'm using and not hours and minutes.
>
> My point is that it seems to me that the dateTime sort does not work
> properly.  What you proposed is a workaround because dateTime does NOT work
> properly, right?
>
> ----- Original Message ----- From: "John Dixon" <dixonja at hotmail.co.uk>
> To: "How to use LiveCode" <use-livecode at lists.runrev.com>
> Sent: Wednesday, April 02, 2014 2:15 AM
> Subject: RE: extremely weird and frustrating...
>
>
>> Another way to do this would be to put a 0 in front of the 'hours & minutes'
>> before you sort them...
>> Alex, it trying to help you... no need to be cheeky !...
>>
>> on mouseUp
>>   set itemdel to ":"
>>   repeat with count = 1 to the number of lines of fld 1
>>      if the number of chars of item 1 of line count of fld 1 = 1 then
>>         put 0 & line count of fld 1 into line count of fld 1
>>      end if
>>   end repeat
>>   sort lines of fld 1
>> end mouseUp
>>
>> would give :
>>
>> 01:22
>> 02:08
>> 07:47
>> 09:14
>> 11:35
>> 12:16
>> 15:56
>> 16:33
>> 25:34
>> 34:55
>>
>>> From: larry at significantplanet.org
>>
>>> Sorry Alex, I do not understand.
>>>
>>> 16:33 is sixteen minutes and 33 seconds.
>>> So why is 25:34 not twenty-five minutes and 34 seconds?
>>> Last time I checked, there are 60 minutes in an hour.
>>
>>> > 25:34 and 34:55 are not valid dateTimes, so where those lines get > sorted
>>> > to is not well undefined; it looks as though LC simply decides to give
>>> > them a '0:00'.
>>> >
>>> > Apart from those two lines, it looks (to me) like the result is > correct.
>>> > Isn't it ?
>>> >
>>> > -- Alex.
>>> >
>>> >
>>> > On 02/04/2014 08:41, larry at significantplanet.org wrote:
>>> >> Here is my script line:
>>> >> sort field myTimes descending dateTime
>>
>>> >> 16:33
>>> >> 15:56
>>> >> 12:16
>>> >> 11:35
>>> >> 9:14
>>> >> 7:47
>>> >> 2:08
>>> >> 1:22
>>> >> 25:34
>>> >> 34:55
>>> >>
>>
>>> >> Here is my other script line:
>>
>>> >> 25:34
>>> >> 34:55
>>> >> 1:22
>>> >> 2:08
>>> >> 7:47
>>> >> 9:14
>>> >> 11:35
>>> >> 12:16
>>> >> 15:56
>>> >> 16:33
>>> >>
>>> >> Seriously?
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>