[FX.php List] Solved? Anyone got a sober solution to a date range search?

[Dale Bengston]

Hmm, we have been date searching with FX and FileMaker 6/7/8 using mm/ 
dd/yyyy...mm/dd/yyyy without incident. I can't vouch for FileMaker 9.

Dale

On Aug 12, 2008, at 3:06 AM, Gjermund Gusland Thorsen wrote:

> Well what I wrote here does not have to do with stored, however there
> is an abstraction layer used for searches with ... and it has a
> peculiar way of not using the same format as the XML RPC delivers to
> use namely MM/DD/CCYY, when performing date range searches
> MM.DD.CCYY...M2.D2.C2Y2 is the formatting of choice.
>
> ggt
>
> 2008/8/12 Tim 'Webko' Booth <tim at nicheit.com.au>:
>>
>> On 12/08/2008, at 9:43 AM, Kevin Futter wrote:
>>
>>> On 12/08/08 9:14 AM, "Tim 'Webko' Booth" <tim at nicheit.com.au> wrote:
>>>
>>>>
>>>> On 11/08/2008, at 8:49 PM, Gjermund Gusland Thorsen wrote:
>>>>
>>>>> I know this worked with Filemaker 5/6
>>>>> ---
>>>>> $q = new FX( $serverIP, $webCompanionPort );
>>>>> $q->SetDBData( $database, 'unit', 'all' );
>>>>> $q->AddDBParam( 'datefield', '1/7/2008...31/7/2008' );
>>>>> $r = $q->FMFind();
>>>>> ---
>>>>>
>>>>> But what is the FileMaker 7/8/9 equivalent on the XML RPC level to
>>>>> FileMaker's: 1.7.2008...31.7.2008 ?
>>>>>
>>>>> :-) Hmm it looks like this works! :-) I just played around with  
>>>>> the
>>>>> characters and numbers.
>>>>> ---
>>>>> $q = new FX( $serverIP, $webCompanionPort );
>>>>> $q->SetDBData( $database, 'unit', 'all' );
>>>>> $q->AddDBParam( 'datefield', '7.1.2008...7.31.2008' );
>>>>> $r = $q->FMFind();
>>>>
>>>> Underneath it all, no matter what your localisation settings, all
>>>> dates are now stored MM/DD/YYYY and searches need to be adjusted
>>>> accordingly
>>>
>>> I'm not sure (or convinced) that they're stored that way Tim, but  
>>> they are
>>> certainly presented to the XML interface in that format, no matter  
>>> what...
>>>
>>> Being in Australia too, I make great use of a little swapDateFormat
>>> function
>>> whenever dates are involved.
>>>
>>> (Internal date storage would be in seconds since epoch, no?)
>>
>> Since 1/1/1970, yes... and 'stored' may have been the wrong word  
>> but the
>> effect is the same...
>>
>> And there is an upside, because it is indeed a valid Unix-style  
>> date, so the
>> date commands/formatting functions can be used on the way out of the
>> database without any further wrangling.
>>
>> Cheers
>>
>> T
>>
>>
>>
>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list