NSMetadataQuery and NSDate: precision problem

Discussion in 'Mac Programming' started by dimaggioel, Oct 13, 2010.

  1. dimaggioel macrumors newbie

    Oct 13, 2010
    I was using NSMetadataQuery to find files which creation date is more recent than a NSDate.
    It seems that NSMetadataQuery cannot find files which creation date is more recent than the specified NSDate for one hour.
    I mean, if the creation date of a file is today at 12:10:50, the query return no result if I set today at 11:10:51 as NSDate, while it founds the file if I set today at 11:10:49.

    Can someone explain me why and how can I solve it?
  2. jared_kipe macrumors 68030


    Dec 8, 2003
  3. chown33 macrumors 604

    Aug 9, 2009
    Post your code.

    There needs to be enough code that someone else can compile it and run it. We can't compile and run descriptions of code.
  4. dimaggioel thread starter macrumors newbie

    Oct 13, 2010
    sorry, you're right.
    Here's the code I wrote
    	NSMetadataQuery *query = [[NSMetadataQuery alloc] init];
    	NSDate *date = [NSDate dateWithNaturalLanguageString:@"2010-09-17 23:18:00"];
    	NSPredicate *predicate = [NSPredicate predicateWithFormat:@"kMDItemFSCreationDate > %@",date];		
    	[query setSearchScopes:[NSArray arrayWithObject:@"[path to directory]"]];	
    	[query setPredicate:predicate];
    	[query startQuery];
    	[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
            [query stopQuery];
            NSLog(@"results : %@",[query results]);
    In the particular directory set as search scope there's only one file, created on 17 Sep at 23:18:36 (saw running stat from terminal).
  5. chown33 macrumors 604

    Aug 9, 2009
    What is your local timezone?

    The NSDate may be interpreted as GMT, since no timezone is given. It certainly does this for me. You can observe this by NSLog'ing the date.

    From the class reference doc for NSDate, description of dateWithNaturalLanguageString (underline added for emphasis):

    The actual metadata of a file should be examined using the 'mdls' command, not 'stat'. Example:
    mdls . path/to/file
  6. dimaggioel thread starter macrumors newbie

    Oct 13, 2010
    I didn't notice that advise, so I must have been lucky because date is translated correctly (I already NSLogged that :) ).
    Even time zone is correct: I'm GMT +2:00 and here's the output of NSLog:
    date = 2010-09-17 23:18:00 +0200
    I was interested only in creation date, not examining all the metadata :) However running mdls:
    kMDItemFSCreationDate          = 2010-09-17 23:18:36 +0200
  7. chown33 macrumors 604

    Aug 9, 2009
    I've tried a number of things here and I simply can't replicate the problem. The results always find exactly the files they're supposed to, even when I specify a date and time to the exact second. Procedure:
    • Enter cmd 'touch example' to create a new file.
    • Enter cmd 'mdls example' to get its actual metadata.
    • Paste its kMDItemFSCreationDate date time tzoffset into the source.
    • Increase the pasted-in date time by one second.
    • Compile and run.
    • Paste the exact date time tzoffset into the source.
    • Change the ">" in the predicate to ">=".
    • Compile and run.

    I think you need to post a complete compilable example that demonstrates the problem. It should include the necessary data files, with the appropriate creation-date to cause the malfunction. You should also identify exactly which OS version, and which architecture you're running (ppc, i386, x86_64).

    Maybe the problem is caused by your machine somehow delaying when it performs metadata scans. So there may be files that were recently created, but they haven't been scanned by the mdimport daemon yet, so they have no metadata in the metadata store, and thus won't be found with a metadata query. Or maybe the file or folder is excluded from Spotlight searches (System Preferences > Spotlight pane). Those are just guesses.
  8. dimaggioel thread starter macrumors newbie

    Oct 13, 2010
    Here is a complete XCode Project:
    (remember to set correctly the search scope of the NSMetadataQuery object).

    I'm on x86_64, MacOS 10.6.4. This problem happens with almost all files (or, at least, all that I tried). However here's a file created this morning at 10:22:05

    Furthermore I noticed that (I don't know if it's normal) spotlight does not find a file just created with touch. I mean if I create a file through finder or through a program it works, but if I create it through touch for a while it's as it doesn't exist...
  9. jared_kipe macrumors 68030


    Dec 8, 2003
    Oddly I have not found a date that would NOT give your example.txt

    EDIT: Ahh because you created it in the future!! (November 14th)
    And a different timezone!

    	for(int i =0;i<[[query results] count];i++) {
    		NSMetadataItem *item = [[query results] objectAtIndex:i];
    		NSLog(@"%@ , %@",[item valueForAttribute:@"kMDItemFSName"], [item valueForAttribute:@"kMDItemFSCreationDate"]);
    EDIT2: Seems to work fine. I changed the minute right around when the file itself says it was created and it seems to work just fine.

    Attached Files:

  10. chown33 macrumors 604

    Aug 9, 2009
    Yes, I now see this with 'touch' on 10.6.3. The query seems to be automatically excluding files that are zero-length from its results. Append one byte to the file and it will appear in the results for me. YMMV.

    Zero-length files are NOT excluded on older OS versions. I happened to be using 10.4.11 when I reported results of my earlier test. YMMV.

    And I still don't see any of the originally reported problem. I don't see a creation-date of Nov 14 on the "example.txt" file, either, so I can only guess what might be happening.

    When was the last time you restarted? Maybe something is wrong with the mdimporter daemon.

    If I were you, I'd submit the test program to Apple's bugreporter. Be sure to include suitable data that reliably causes the problem, or a procedure for creating files that reliably show the problem. The uploaded example.txt doesn't show the problem, because its metadata wasn't included, AFAICT.

    You may have trouble archiving a file with the metadata to show the problem, so I suggest concentrating on a series of commands, perhaps using echo or touch, that can create a local file with the proper metadata.

  11. dimaggioel thread starter macrumors newbie

    Oct 13, 2010
    I don't know how I could create it in the future (it would be nice) :)
    on my computer:
    kMDItemFSCreationDate      = 2010-10-14 10:22:05 +0200

    It seems not to be that simple...zero-length files created from a program (for example TextEdit) or files born with a length different from 0 and then emptied (i.e. launch echo "test" > file.txt, then open file.txt with an editor and empty it) are correctly found by spotlight.

    Besides, I'm not 100% sure, but I think I have a couple of empty files created with touch and correctly found by spotlight...

    Last time...about five minutes ago. However, I turn it off every day when I go to bed.

    The problem is that I cannot tell to Apple much more than what I can tell to you...Actually what I did is not so much different from what you did to test the code:
    • create a file calling touch file1.txt
    • try to find it with Test (0 results)
    • try to find it with Spotlight (0 results)
    • launch echo "example" > file1.txt
    • try to find it with Spotlight (found)
    • call mdls file1.txt and get the exact creation date
    • insert the exact creation date less a second as date in Test and search (0 results)
    • insert the exact creation date less an hour and a second in Test and search (found)

    same thing if, instead of using NSDatePicker to get the date (even if I don't think there are problems about it), I insert it manually in the code, calling dateWithNaturalLanguageString or even dateWithString (the correct format is the one showed by mdls).
    Furthermore, I followed these identical instructions on a friend's mac (10.6.4 if I don't get wrong) with the same results.

    Sorry, I missed your post, but actually is exactly what I'm thinking of...In fact normally I should be GMT+1, not +2 as it's in this period of the year.
    But examining the metadata of the file I read
    kMDItemFSCreationDate      = 2010-10-14 10:22:05 +0200
    so it should understand that the file has been created during daylight saving time and results should be coherent with that. Besides, setting the date (manually or through NSDatePicker) the date is 2010-10.... +0200, so it should work correctly...
  12. jared_kipe macrumors 68030


    Dec 8, 2003
    LOL You missed the first reply to your own thread?!

    Anywho, your file seems to be messed up at least after I downloaded it. Your program though seems to run and behave perfectly on my computer.
    I'm running 10.6.3 how about you?
    Maybe copy your program into /Applications and make a new user on your computer to test it out.
  13. dimaggioel thread starter macrumors newbie

    Oct 13, 2010
    Sorry for the late, I have been away

    Yes I missed your post because I went directly to the last message and jumped over your... :p

    However probably you were right! I tried to run the application on a friend's mac (running 10.6.3) and the result was the same as mine.
    Yesterday we changed to winter time; today I tried again to execute the program on my mac (10.6.4) and it works perfectly.

    I think now there's very few I can do...
    When chown suggested me to I submitted the test program to Apple, explaining also that the problem may be caused by daylight saving time. Only hope they'll answer soon...
    Isn't there a way to know if they read it or not?
  14. jared_kipe macrumors 68030


    Dec 8, 2003
    I don't know, but maybe you could fix it yourself by doing some appropriate testing of the runtime computer. Possibly add a category to NSDate to do that testing to make it easy.
  15. dimaggioel thread starter macrumors newbie

    Oct 13, 2010
    Well, if I have to be sincere, I don't know where to start from for try solving it on my own (except some kind of workaround but, of course, that's not a fix). For how I see it, the problem is somewhere in the way NSMetadataQuery perform search, since metadata seems to be stored correctly and I did not found problems in comparisons between NSDate objects...

Share This Page