format for datetime filed when specifying filter for Outlook::_Items Find function

  • Thread starter Thread starter Jerry Gao
  • Start date Start date
J

Jerry Gao

The Outlook::_Items.Find function requires a filter string. In my outlook
c++ addin, I want to include as part of the filter string something like
this:

"[ReceivedTime] > '9/27/2004 3:47PM'". However, the filter doesn't work
because the format of the date time value is not correct. Does someone know
the correct format outlook requires?

thanks.
 
I found out myself that outlook expects formats below:
09/27/2004 15:47
09/27/2004 03:47 PM
9/27/2004 15:47

As long as it doesn't contain the format for the second, it will work.
 
I just found the same thing... which pretty much sucks, imho, because
LastModifiedTime date resolution is finer than "to the minute"! So that
leaves a potential 60 second margin of error.

I suppose in practice this won't often be a show-stopper... but why couldn't
they have documented it, saving you and I and countless others the time and
frustration of trial and error?

Or maybe go crazy and truncate seconds internally? As we know, it isn't
that hard, but how much sense does it make for each of us to have to roll
our own?

shaking my head...

-Mark



Jerry Gao said:
I found out myself that outlook expects formats below:
09/27/2004 15:47
09/27/2004 03:47 PM
9/27/2004 15:47

As long as it doesn't contain the format for the second, it will work.

Jerry Gao said:
The Outlook::_Items.Find function requires a filter string. In my outlook
c++ addin, I want to include as part of the filter string something like
this:

"[ReceivedTime] > '9/27/2004 3:47PM'". However, the filter doesn't work
because the format of the date time value is not correct. Does someone know
the correct format outlook requires?

thanks.
 
I found out internally the 'ReceivedTime', 'LastModificationTime' are all
stored to seconds. The display in outlook is round off value to minutes. So
to ensure the filter string is correct to find the items, i need to do
somthing like this [ReceivedTime] >= 9/27/2004 15:47 AND [ReceivedTime] <
9/27/2004 15:48.

-Jerry

Mark J. McGinty said:
I just found the same thing... which pretty much sucks, imho, because
LastModifiedTime date resolution is finer than "to the minute"! So that
leaves a potential 60 second margin of error.

I suppose in practice this won't often be a show-stopper... but why couldn't
they have documented it, saving you and I and countless others the time and
frustration of trial and error?

Or maybe go crazy and truncate seconds internally? As we know, it isn't
that hard, but how much sense does it make for each of us to have to roll
our own?

shaking my head...

-Mark



Jerry Gao said:
I found out myself that outlook expects formats below:
09/27/2004 15:47
09/27/2004 03:47 PM
9/27/2004 15:47

As long as it doesn't contain the format for the second, it will work.

Jerry Gao said:
The Outlook::_Items.Find function requires a filter string. In my outlook
c++ addin, I want to include as part of the filter string something like
this:

"[ReceivedTime] > '9/27/2004 3:47PM'". However, the filter doesn't work
because the format of the date time value is not correct. Does someone know
the correct format outlook requires?

thanks.
 
Actually, they're stored internally as variant dates, and have a much finer
resolution than seconds. If you add this to an Outlook/VB date, it'll add
just a tiny bit more than one second to the time it displays:
0.00001157408.

So it's theoretical resolution is sub-microsecond. What exactly it's
practical resolution is I'm not certain, but my observation is that it's
finer than 3.33 ms. This is based on working with SQL Server dates that are
documented to be accurate to 3.33~ ms. (And I've proven it out at the
binary level as well.)

If you store a date from OL in a SQL table, then read it back and compare it
to the same OL date, they will almost never be equal. This doesn't kill me
because I'm testing whether or not the item's date is greater than the
db-stored date (indicating that the item has changed since last examined.)
For this to work out right I have to add 1 second to the SQL date before
comparing.

Just another one of those little things that implements seemingly sound
logic in a way that behaves insanely when viewed from the surface...

-Mark




Jerry Gao said:
I found out internally the 'ReceivedTime', 'LastModificationTime' are all
stored to seconds. The display in outlook is round off value to minutes.
So
to ensure the filter string is correct to find the items, i need to do
somthing like this [ReceivedTime] >= 9/27/2004 15:47 AND [ReceivedTime] <
9/27/2004 15:48.

-Jerry

Mark J. McGinty said:
I just found the same thing... which pretty much sucks, imho, because
LastModifiedTime date resolution is finer than "to the minute"! So that
leaves a potential 60 second margin of error.

I suppose in practice this won't often be a show-stopper... but why couldn't
they have documented it, saving you and I and countless others the time and
frustration of trial and error?

Or maybe go crazy and truncate seconds internally? As we know, it isn't
that hard, but how much sense does it make for each of us to have to roll
our own?

shaking my head...

-Mark



Jerry Gao said:
I found out myself that outlook expects formats below:
09/27/2004 15:47
09/27/2004 03:47 PM
9/27/2004 15:47

As long as it doesn't contain the format for the second, it will work.

The Outlook::_Items.Find function requires a filter string. In my outlook
c++ addin, I want to include as part of the filter string something like
this:

"[ReceivedTime] > '9/27/2004 3:47PM'". However, the filter doesn't
work
because the format of the date time value is not correct. Does someone
know
the correct format outlook requires?

thanks.
 
Back
Top