Date and time representation

A date/time value must be given in ISO 8601 format:

YYYY-MM-DDThh:mm:ss.ss

 where:

 All components except the year are optional.

Time zone designators

A date/time value may optionally be followed by a time zone designator, which can be in one of the following formats:

+hh
-hh
+hh:mm
-hh:mm
Z

where hh is the number of hours and mm is the number of minutes difference from universal time (UTC). For example, +02:00 indicates a time zone "UTC - 2 hours", where the time is 14:00 (2 pm) while it is 12:00 (12 am) in UTC. The minutes part is optional, so the time zone designator can also be written as -02, which also means "UTC - 2 hours". A time zone indicator of Z means that the time zone is UTC, and it is preferred over +00:00.

If no time zone indicator is given, the date/time value is expressed in server local time. Currently, this is the Windows time zone set on the FotoWeb server. In future versions, this will be a configuration option.

Number representation

Numbers can be given as integer or floating-point numbers in the same syntax as in the JSON language (external link):

123
-123
123.456
-0.123
0.123e+4
0.123e-4
00123
+123

Leading zeroes or plus signs are ignored.

FotoWeb search only supports integer numbers, so all numbers are converted to integers internally. For example, a search for {{0.5 TO 123.456}} is equivalent to a search for 0 TO 123.

Searching for numbers and date/time values

It may not always be the user's intention to search for a date/time value or number. For example, a search expression of 000123 looks like a number, but it may be a literal string that represents a unique identifier. The zeroes may be important, but if the expression is interpreted as a number, they will be stripped. Other examples:

• A user may want to search for a unique identifier that looks like a date; for example, 1234-01-01-01. If interpreted as a date, the date would be out of range and invalid (FotoWeb only supports searches for dates after 1601-01-01).
• A user may want to search for an international phone number; for example, +47000000. If interpreted as a number, the leading plus sign would be stripped.

Therefore, it depends on context (predicates) whether FotoWeb interprets an expression as a number, a date/time value, or just a literal string. The rules are as follows:

• If a date/time value is expected in the search context, then FotoWeb interprets all terms as date/time values. Any other terms make the predicate invalid and match nothing.
• If a number is expected in the search context, then FotoWeb interprets all terms as numbers. Any other terms make the predicate invalid and match nothing.
• If text is expected in the search context, then FotoWeb interprets all terms as literal strings. Numbers and dates are, therefore, interpreted literally and have no special meanings.
• When doing a full-text search, FotoWeb interprets all terms as literal strings. Numbers and dates are, therefore, interpreted literally and have no special meanings.

The search context depends on what predicates are used. Here are some examples:

If the search context is a metadata field, the interpretation of terms depends on the field type in the metadata configuration: date/time values, numbers, or literal strings. For example, the following standard fields have the following types:

Time zone conversion

Search expressions can be given in different time zones:

• Universal time (UTC), for example, 2023-05-17T00:00:00Z
• Server local time, for example, 2023-05-17T00:00:00
• A specific time zone, for example, 2023-05-17T00:00:00+05:00

Not all searchable attributes contain time zone information. While the XMP standard specifies that date/time values in metadata fields may be in ISO 8601 format, which may include time zone information, certain attributes, such as file modification time, are not specified in any particular time zone. Time zone information may be useful, and time labels in local time zones may be more intuitive for users in certain regions. However, when searching, a user is typically only interested in whether a date/time value stored in an asset matches the (physical) point in time or time range specified in the search query, regardless of the time zone. For example, if a photo was taken in New York City at 5 am US Eastern Time and a photo editor in Berlin searches for a date/time range in Central European Time, then the photo editor is interested in whether the photo was taken during that time range and not what time the clocks showed in New York, Berlin, or Greenwich.

Therefore, when searching, all date and time values in the query are internally converted to Coordinated Universal Time (UTC). All date/time values stored in assets are also indexed in universal time (UTC), although they may be stored and displayed in a different time zone. Being able to search in different time zones is, therefore, only a convenience for the user. Technically, all searches are in UTC.

Date ranges and incomplete dates

Date values are most useful when used in range expressions. For example, the following expression:

mt:2023-05-17 TO 2023-05-18

matches all assets that were modified on the 17th of May 2023.

Ranges are a bit tedious to write, so there is a shorthand:

mt:2023-05-17

In this expression, the date/time value is incomplete: It consists only of the date and does not include the time. If an incomplete date/time value appears outside of a range, then it is implicitly converted to a range according to the following rules:

Incomplete date/time values that appear in ranges are not converted to ranges but expanded to complete date/time values by "adding zeroes" as follows:

A range always includes the left operand but excludes the right operand. For example, the expression

mt:2021 TO 2023

matches all assets modified in the years 2021 and 2022, but not those modified in the year 2024. If both operands of a range are equal, then the range is empty, and the term matches nothing.

Dynamic date and time tags

To learn about using dynamic date and time tags in search expressions, see Date and time tags.