Merge pull request #532 from IBM/lee-master-patch

Resolve logical conflict in Conformance.md

Author: prb112

docs/src/pages/Conformance.md

@@ -124,15 +124,12 @@ The `eb` and `ap` prefixes are not supported for searches which target values of
 If not specified on a query string, the default prefix is `eq`.
 
 ### Searching on Date
-The IBM FHIR Server adheres to the specification with two minor exceptions:
-* The server supports search query values with fractional seconds; any search query value given with fractional seconds is treated as precise value, whereas search query values without fractional seconds are handled as an implicit range (e.g. `2000-04-30T23:59:00` becomes the range `[2000-04-30T23:59:00, 2000-04-30T23:59:01)`).
-* Dates and DateTimes (and query parameter values for date search parameters) which are expressed without timezones are handled as UTC values.
-* This differs slightly from the specification which indicates that "Where both search parameters and resource element date times do not have time zones, the servers local time zone should be assumed". However, because both the element values AND search query parameters are handled in the same way, this difference matters only when timezones are specified on one side (resource element or search query parameter) but not the other. For example, a query like `Patient?birthdate=2019-01-01` would match a resource with a value of `2019-01-01`, but would *not* match a resource with a value of `2019-01-01T20:00:00-04:00`.
+The IBM FHIR Server implements date search as according to the specification.
 
-The IBM FHIR Server supports up to 6 fractional seconds (microsecond granularity) for Instant and DateTime values and all extracted parameter values are stored in the database in UTC in order to improve data portability.
+The server supports up to 6 fractional seconds (microsecond granularity) for Instant and DateTime values and all extracted parameter values are stored in the database in UTC in order to improve data portability.
 
 Dates and DateTimes which are expressed without timezones are assumed to be in the local timezone of the application server at the time of parameter extraction.
-Similarly, query parameter date values with no timezone are assumed to be in the local time of the server at the time the search is invoked.
+Similarly, query parameter date values with no timezone are assumed to be in the local timezone of the server at the time the search is invoked.
 To ensure consistency of search results, clients are recommended to include the timezone on all search query values that include a time.
 
 Finally, the server extends the specified capabilities with support for "exact match" semantics on fractional seconds.