> For the complete documentation index, see [llms.txt](https://guides.noloco.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guides.noloco.io/views/display/calendar.md). # Calendar {% embed url="" %} Calendar view is often the right choice if you have event-based data and want to make scheduling a breeze for your team. In this video, learn how to: * Use the calendar view display option * Choose the default calendar view (month, week, work week, day) * Group records by a particular field so they show the same colour * Control what fields get shown in the record pop-up * Add [in-app filters](/views/filter-fields.md) so your team can filter records from the action bar ### Date Formats #### Depending on the type of date field you're using, Noloco will display your calendar events differently. Date Time Fields If your field has a date and time, then Noloco will (unless specified) display this in the user's local timezone. If you don't include an end date, the event will default to one hour long. A few examples of events with date times: * Meetings that start and end at specific times * Bookings that start and end at specific times #### Date only Fields If your field has only a date (and no time) then Noloco will display these as all-day events, using the date of the event, ignoring the user's timezone. A few examples of events without dates: * Birthdays * Multi-day events such as conferences * Single-day events that don't have a specific start or end date #### Mixing date-time fields with all-day events: If you need to display both variable-time events and all-day events on the same calendar, it can be quite confusing to get this right with time zones. But thankfully, it is possible to do so in Noloco. Because you need to specify event start and end times, you'll need to use a date-time field. But to indicate to Noloco that an event is an all-day event, regardless of timezone, **you can make the event start at midnight UTC** (that's not your local timezone). I.e., if you have an event that's meant to happen on February 1st, you would set the date to be `1st Feb 00:00` or as an ISO string `2023-02-01T00:00:00.000Z` Similarly, to indicate that it's an all-day event, you need to set the end date to have the same value. That is to say, the event is only on that day. If an event needs to span multiple days, but be treated as an all-day event, regardless of timezone, you can adjust the end date to be on the last day of your event, but make sure its time is midnight UTC (`00:00`) Below is an example where we mix all-day and specific event time events:
Sample data | Name | Start | End | | --------------------------- | ---------------- | ---------------- | | Multiple days - non all-day | 03/02/2023 00:00 | 04/02/2023 11:30 | | Starts at midnight | 03/02/2023 00:00 | 03/02/2023 05:00 | | Multiple Days | 01/02/2023 00:00 | 04/02/2023 00:00 | | All Day 1 | 02/02/2023 00:00 | 02/02/2023 00:00 | | All Day 2 | 03/02/2023 00:00 | 03/02/2023 00:00 | | Two hours long | 05/02/2023 14:00 | 05/02/2023 16:00 | | | | | ### Event fields In addition to a date or date range, you can map a **Start time**, **End time**, and **Title** field to each event: * **Start Time** – Defines when an event begins. * **End Time** – Defines when an event finishes. * **Title** – Sets the label shown on each event so it's easy to identify at a glance. Together these make it easier to manage multi-hour or multi-day events and give you more accurate scheduling and visualisation inside the calendar. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://guides.noloco.io/views/display/calendar.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.