macOS NSMetadataQuery and NSDate: precision problem

dimaggioel · Oct 13, 2010

Hi,
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?

jared_kipe · Oct 13, 2010

Probable daylight savings time error.

chown33 · Oct 13, 2010

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.

dimaggioel · Oct 13, 2010

chown33 said:
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.

sorry, you're right.
Here's the code I wrote

Code:

	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).

chown33 · Oct 13, 2010

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):

This method supports only a limited set of colloquial phrases, primarily in English. It may give unexpected results, and its use is strongly discouraged.

http://developer.apple.com/library/...Classes/NSDate_Class/Reference/Reference.html

The actual metadata of a file should be examined using the 'mdls' command, not 'stat'. Example:

Code:

mdls . path/to/file

dimaggioel · Oct 13, 2010

chown33 said:
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):

http://developer.apple.com/library/...Classes/NSDate_Class/Reference/Reference.html

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:

Code:

date = 2010-09-17 23:18:00 +0200

chown33 said:
The actual metadata of a file should be examined using the 'mdls' command, not 'stat'. Example:

Code:

mdls . path/to/file

I was interested only in creation date, not examining all the metadata

However running mdls:

Code:

kMDItemFSCreationDate          = 2010-09-17 23:18:36 +0200

chown33 · Oct 13, 2010

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.
OR
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.

dimaggioel · Oct 14, 2010

Here is a complete XCode Project:
http://www.mediafire.com/?3rmj31m042js8ss
(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
http://www.mediafire.com/?fqxn9vcd0rbddw4

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...

jared_kipe · Oct 14, 2010

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!

Code:

	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.

chown33 · Oct 14, 2010

dimaggioel said:
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...

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.

http://developer.apple.com/bugreporter

dimaggioel · Oct 14, 2010

jared_kipe said:
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!

I don't know how I could create it in the future (it would be nice)

on my computer:

Code:

kMDItemFSCreationDate      = 2010-10-14 10:22:05 +0200

chown33 said:
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.

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...

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

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

chown33 said:
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.

http://developer.apple.com/bugreporter

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.

jared_kipe said:
Probable daylight savings time error.

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

Code:

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...

jared_kipe · Oct 20, 2010

dimaggioel said:
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

Code:

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...

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.

dimaggioel · Nov 1, 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...

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?

jared_kipe · Nov 1, 2010

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.

dimaggioel · Nov 4, 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...

Search

Search

macOS NSMetadataQuery and NSDate: precision problem

dimaggioel

macrumors newbie

jared_kipe

macrumors 68030

chown33

Moderator

dimaggioel

macrumors newbie

chown33

Moderator

dimaggioel

macrumors newbie

chown33

Moderator

dimaggioel

macrumors newbie

jared_kipe

macrumors 68030

Attachments

chown33

Moderator

dimaggioel

macrumors newbie

jared_kipe

macrumors 68030

dimaggioel

macrumors newbie

jared_kipe

macrumors 68030

dimaggioel

macrumors newbie

Our Staff