> For the complete documentation index, see [llms.txt](https://docs.hos.accessacloud.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hos.accessacloud.com/atreemo-api/get-started/introduction/dates-and-times.md).

# Dates and times

Operation-specific Atreemo date and time handling

{% hint style="warning" %}
**Beta, runtime validation pending.** Date handling is operation-specific. A CLR `DateTime` or OpenAPI `date-time` format does not prove that every value is UTC, local venue time or a date-only business value.
{% endhint %}

## Representation

Use the format stated by the individual schema. For JSON `date-time` fields, an ISO 8601 value with an explicit offset avoids ambiguous display conventions. This is client guidance, not proof that the backend preserves the original offset or applies one universal time-zone conversion.

```json
{
  "EventStartDate": "2027-06-01T10:00:00Z",
  "EventEndDate": "2027-06-01T12:00:00Z"
}
```

These are synthetic date fields, not a complete event request. Keep the offset meaningful. Do not append `Z` to an unknown local time merely to make it look valid. Agree the business time zone, daylight-saving treatment and range boundaries with the owner before processing records.

For URI/query values, percent-encode reserved characters: a literal `+` offset should be `%2B`, not left to form-style decoding as a space. Do not convert a native string/date parameter to an invented epoch value.

## Source-verified differences

Citations refer to source commit `ea9cb106e13aa4b9b92c01d090118742b44dd470`.

| Operation or model              | What source establishes                                                                                                                                          | What remains unverified                                                              |
| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Transaction/GetOrdersByCustomer | Nullable `fromDate`/`toDate`; reversed ranges are rejected and values are forwarded to order-history logic (`TransactionController.cs:133–147,177–180,213–222`). | Procedure precision, comparisons, deployed time zone and stable ordering.            |
| Event/PostEvent                 | The action checks and maps event dates (`EventController .cs:143–183`).                                                                                          | Commented-out chronology checks are not enforcement.                                 |
| AddToMyGoogleCalendar           | Source formats start/end values with a suffix ending in `UserTZOfSet` (`AddToMyCalendarController.cs:226–228`).                                                  | Appending a suffix is not proof of instant conversion or time-zone database support. |
| Loyalty/EarnFromReceipt         | Rejects `DateTime.MinValue` and forwards `TransactionDateTime` (`LoyaltyController.cs:1975–1994`).                                                               | Universal date truncation, business-day boundary or UTC conversion.                  |
| BIDWHouse/Post                  | Forwards `StartDate` into extraction setup (`BIDWHouseController.cs:62–85`).                                                                                     | Omission is not a verified safe default.                                             |
| SalesLeads/GetLeads             | Several date members are native strings forwarded to a procedure (`SalesLeadsController.cs:411–415`; `Models/Lead.cs:2777–2794`).                                | A universal parser, format or time zone.                                             |

## Null, omission and PATCH

A nullable date can differ from an omitted JSON property. HotelBooking and SalesLeads use custom PATCH binders that track selected keys; do not submit every field as null when only one value should change. `DateTime.MinValue` is not a safe replacement for an unknown date.

Before an approved test, record the field's business meaning, offsets and daylight-saving handling, omitted/null behaviour, range boundaries, precision, ordering and privacy-safe before/after evidence. See [Request format](file:///8924120/request-format.md), [Paging](broken://pages/fcb8b4932103ca3d407e794073b04fe81184636c) and [Testing and support](file:///8924120/testing-and-support.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.hos.accessacloud.com/atreemo-api/get-started/introduction/dates-and-times.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.