rcp19, dates, and timestamps

[bryanburgers]

The original specification for RCP19 seem to indicate that "dates" and "times" are synonymous.

https://github.com/RESOStandards/reso-transport-specifications/files/8384860/RESOWebAPIRCP-RCP-WEBAPI-019ValidationExpressionintheWebAPI-300322-2353.pdf

The DATE and TIME functions are synonyms.

Token	Data Type	Description
.TODAY.	TIME	The current date.
.NOW.	TIME	The current time.

In practice, MLSes that return RESO values clearly differentiate between

• Dates
  • typically, something the agent manually enters
  • looks like 2023-04-21
  • E.g. CloseDate, ExpirationDate, OnMarketDate.
  • "This is the date entered by the agent reflecting when the change occurred contractually, not a timestamp of when the change was made in the MLS.)
• Timestamps
  • typically an instant in time generated by the MLS
  • looks like 2023-04-21T12:34:56.135Z if we're lucky, or 2023-04-21T12:34:56.135
  • E.g. ModificationTimestamp, OriginalEntryTimestamp, OnMarketTimestamp
  • "The transactional timestamp automatically recorded by the MLS system representing..."

I'd like to see the RCP19 spec clearly differentiate between these two types.

Especially, the spec defines addition and subtraction between times and floats.

Operator	Left operand	Right operand	Result	Meaning
+	TIME	FLOAT	TIME	Time shift
-	TIME	FLOAT	TIME	Time shift
-	TIME	TIME	FLOAT	Time shift

Where the float seems to indicate a number of days.

For timestamps, specifying a time shift as a float (some fraction of a day) is fine. For dates, specifying a time shift as some fraction of a day doesn't make sense.

E.g., if the contractual OnMarketDate is 2023-04-21, what does OnMarketDate + 0.5 evaluate to? 2023-04-21 because we add less than one day? 2023-04-22? 2023-04-21T12:00:00Z assumes the the contractual date is midnight UTC, which isn't ideal.

Converting the date to a timestamp and doing the addition also doesn't always make sense; If the OnMarketDate just happens to be near the DST boundary, adding one full day (86400 seconds) might result in an off-by-one error.

https://rules.zenlist.dev/?gist=00baa24bce05326377f0d9729bbbd69f