Four criteria, inside and outside Clio Operate, affect the behaviour and format of dates in the application.

How dates are stored

Clio Operate stores every date and time in UTC (Coordinated Universal Time). Time zone settings never change the stored value. They control how Clio Operate displays the value, and the time zone that it uses to calculate and output dates.

How the layers combine

• Regional Settings sets the environment default. A work item created in an environment set to London inherits London as its work item time zone.
  
• Every work item created, for example a matter, inherits the default time zone set in Regional Settings.
  
• A work item without its own time zone uses the time zone of its nearest ancestor that has one, for example a Statement of Work. For details, see the Work item time zones tab.
• A user profile time zone overrides what that individual sees. A user based in Copenhagen selects the Copenhagen time zone on their profile and sees times converted to Copenhagen local time.
  
• Where the time zone of a date differs from the user time zone, Clio Operate displays a globe icon. Hovering over the icon displays the date and time in the date's own time zone. For most dates, that is the work item time zone.
• Where the two match, no globe icon appears.
• The browser controls format only, never the underlying value.

Daylight saving

Clio Operate adjusts displayed dates and times automatically for daylight saving. In the UK, British Summer Time (BST) is UTC+1. In winter, clocks go back to Greenwich Mean Time (GMT), which is UTC+0. The offset between two locations therefore changes across the year. Singapore is eight hours ahead of the UK in winter and seven hours ahead during BST. Allow for this when testing, because a configuration verified in winter behaves differently in summer.

Select the right time zone

Each entry in a time zone list is a named time zone, not a fixed offset. The label displays the standard offset from UTC, for example (UTC+10:00) Canberra, Melbourne, Sydney. Clio Operate applies the daylight saving rules for that time zone, so the actual offset changes in summer.

Select the entry for the place, not an entry that has the right offset today. For example, Brisbane and Melbourne have the same standard offset, but only Melbourne observes daylight saving. A user in Melbourne who selects (UTC+10:00) Brisbane sees times one hour wrong in summer.

Every work item, for example a matter or a task, has a work item time zone. Clio Operate uses it as the reference time zone for the dates on that work item.

How a work item gets its time zone

Clio Operate uses the first time zone that it finds, in this order:

• The time zone set on the work item itself.
• The time zone of the nearest ancestor that has one, for example the matter that a task sits under.
• The Default time zone in Regional settings.
• UK time (Europe/London), if Regional settings has no default time zone or is not enabled.

Clio Operate does not copy a time zone onto a new work item. It looks up the time zone each time that it needs it. A work item without its own time zone therefore follows any later change to its ancestors or to Regional settings.

What the work item time zone controls

• The globe icon. Where the time zone of a date differs from the user's time zone, a globe icon displays next to the date. Hovering over it displays the date in that time zone, for example "In key date time zone:" on a key date.
• Date-only key dates. Clio Operate saves a date-only key date at the start of the working day in the work item time zone. See the Key Dates tab.
• Generated documents. Where a date has no time zone of its own, Data Composer converts it to the work item time zone. See the Documents and Data Composer tab.

The work item time zone does not change what a user sees on screen. The time zone on the user's profile controls that.

Let users set the time zone of a work item

In Modeller, add the Time Zone aspect to the blade of the work type. Users can then set the time zone of each work item. For the aspects that are available, see All Aspects in Clio Operate.

The aspect adds a Time Zone field to the work item. The aspect has display settings only. It has no setting that controls the default time zone.

Where the field is set to (inherited), it displays a message that names the time zone that the work item inherits, for example "This Work Item will use the ' (UTC+00:00) Dublin, Edinburgh, Lisbon, London ' time zone".

A user who can edit the work item can change its time zone after the work item is created. Dates that are already saved keep their stored UTC value, so the time that each user sees does not change.

In Data Composer, the Local value of some key dates follows the work item time zone. After you change the time zone of a work item, check the dates in its generated documents.

Clio Operate captures key dates in a locale-agnostic form. Display depends on the three layers described in the Overview tab.

Time zone behaviour

• The due date and time display according to the time zone set on the user’s profile.
• The work item time zone is inherited from Global Features > Regional Settings, or from the nearest ancestor work item that has its own time zone.
• A key date is saved with the time zone of its work item. Where that time zone differs from the user time zone, a globe icon appears next to the key date. Hovering over it displays the date and time under "In key date time zone:".

Worked example 

A user in London has London set on their profile.

The user schedules an Exchange Date for 9am on 19 May on a London work item. The key date displays as 9am with no globe icon.

The same user changes their profile time zone to Berlin.

The key date now displays as 10am, with a globe icon displaying the work item date and time of 9am.

The work item time zone changes to Singapore.

The key date still displays as 10am for the Berlin user. The hint still displays 9am, because the key date keeps the London time zone that it was saved with.

The fee earner moves to the Singapore office and sets their profile time zone to Singapore. The key date displays in Singapore local time. The globe icon still displays, because the key date time zone is London, not Singapore.

Format behaviour

The current user’s browser settings determine the format of the date. Changing the browser language to English (United States) presents all key dates in the US standard MM/dd/yyyy.

The Chrome language setting changed to English (United States)

Start times

The default start time of the Key Date Time element comes from a value held in the database for each Working Day Calendar. A UK calendar typically defaults to 9am. A German calendar typically defaults to 8am, reflecting local office hours.

The default time applies in the work item time zone. For example, on a matter in the Mountain Time zone, a user in London sees a new key date default to 4pm, which is 9am in Denver.

Date-only key dates

A key date that displays as a date only still has a time. Clio Operate saves it at the start of the working day in the work item time zone, then stores it in UTC.

The stored UTC value can fall on the previous day. For example, 9am on 14 May in Sydney is 11pm on 13 May in UTC. A user whose own time zone is many hours behind the work item time zone can also see the previous day.

In Data Composer and document templates, use the Local value of the key date, not the UTC value. See the Documents and Data Composer tab.

The rules that apply to key dates apply equally to tasks in the work list.

• The due time displays in the time zone set on the viewing user’s profile.
• Where the user time zone differs from the time zone of the due date, a globe icon appears. Hovering over it displays the due date and time in that time zone.
• The browser determines the format of the task due date.

Worked example 

A task to review court evidence is scheduled at 9am on a London matter by a local user.

A user based in Germany viewing the same task sees a due time of 10am with a globe icon. Hovering over the icon displays the work item due date and time.

A user viewing the task in a US browser sees the same value in MM/dd/yyyy format.

Where Regional settings is enabled, the due date of a task has its own Time Zone field. On a new task, the field defaults to the Default time zone in Regional settings, not to the time zone of the matter. To book a due date in another time zone, the user changes the field.

Scenarios

These scenarios walk through the combined behaviour. All examples assume the UK clocks show GMT (UTC+0).

Sara works in London, Hans works in Berlin, Lily works in Singapore. Each has their profile time zone set accordingly.

Scenario A: task created on a London work item

The work item is based in London. Sara creates a task to review the evidence on a file and sets the due date to 10am on 10 October.

User	Displayed due time	Globe icon
Sara and other UK users	10am	No
Hans in Berlin	11am	Yes, displaying 10am in the work item time zone
Lily in Singapore	6pm Singapore is eight hours ahead under GMT, rather than seven hours ahead during British Summer Time.	Yes, displaying 10am in the work item time zone

 

 

Working Day Calendars capture non-working days, such as public holidays. Workflow processes reference these calendars so that date calculations exclude non-working days, for example to prevent a deadline falling due on a public holiday.

Create multiple calendars to capture non-working days for different countries or regions, including individual state and federal holidays.

Maintain a Working Day Calendar

1. Navigate to Admin > Users > Working Day Calendar.
   
2. Select New at the top right of the page to create a new Working Day Calendar.
3. Select an existing calendar from the Calendar drop down to display its non-working days.
   
   
4. Select the menu options to the right of a date to edit or delete it.
5. Select the plus icon at the top right of the widget to add a new date.

Assign a calendar to a user

Assign a Working Day Calendar to each user from the Personal Details blade of their user profile.

Each Working Day Calendar also holds the default start time used by the Key Date Time element. See the Visual Workflows tab for the effect of calendar assignment on working day calculations.

Each appointment has its own time zone, in the Time Zone field on the appointment blade. On a new appointment, the field defaults to the Default time zone in Regional settings. It does not default to the time zone of the matter, or to the time zone of the user who creates the appointment.

The Time Zone field displays when the Regional settings global feature is enabled. The appointment aspect has no setting that hides the field or changes its default.

How the appointment time zone works

On the appointment blade, the start and end times are in the appointment's time zone. A change to the time zone keeps the times that are entered, and changes the moment that Clio Operate stores.

For example, a user in London books a hearing in Sydney at 10am Sydney time. The user selects (UTC+10:00) Canberra, Melbourne, Sydney in the Time Zone field, then enters 10am. Each attendee sees the hearing at the correct time in their own time zone.

Outside the appointment blade, the standard rules apply:

• The current user profile time zone determines the displayed time.
• Daylight saving adjustments apply automatically.
• Browser settings determine the display format.

Appointments in Outlook

From Clio Operate 7.13, timed appointments sync to Outlook in UTC. In Outlook, these events display (UTC) Coordinated Universal Time as their time zone. The time of the event displays correctly in each user's own time zone.

All-day appointments sync as all-day events on the date in the appointment's time zone.

Form Builder offers two date related field types.

Two field attributes control how the value is stored and displayed.

Type 3 fields that have a displayFormat attribute are stored as UTC. This affects both the date and the time element.

Effects of type and displayFormat settings

Consider an Incident Date field set to type 3, Date Time.

The attributes are set to present the date only.

Because the field type is date/time and displayFormat is set, Clio Operate captures the value in UTC. The stored start time of the Incident Date is midnight between the 13th and the 14th.

• During British Summer Time, UTC is local time minus one hour, which is 11pm on the 13th. The date component therefore displays as the 13th.
• Once the clocks go back to winter time, UTC is local time plus zero hours. The date component is midnight of the 13th to 14th and displays correctly as the 14th.

To avoid this, set the Form Builder type to 2, Date only. Type 2 stores the date alone and is not subject to time zone changes or daylight saving.

The same principle applies to the time element. Where the field type is 3 and displayFormat is applied, Clio Operate captures the value in UTC. UTC is one hour behind local time during British Summer Time, so the time element shifts across the changeover. To fix the time element so it does not change with the time zone or the spring and autumn changeover, apply the format attribute so that the value returns as a string rather than a date/time.

Locale safety

A date field is locale-safe if, and only if, it has an explicit displayFormat set in the form definition. With this attribute, Clio Operate stores the date in ISO 8601 format and each user sees their browser locale rendering.

Without it, the displayed string is what gets stored. A US user misreads a UK entered 03/04/2026, and the reverse also applies.

Locale comes from the browser only. There is no per-user or per-work-type date format setting today.

Task due dates and key dates presented in list views follow the same rules described above:

• The current user profile time zone determines the displayed time.
• Daylight saving adjustments apply automatically.
• Browser settings determine the default display format.

Where a date presented in a list view uses the Date or DateTime format, configurators can set the format of the displayed date. This applies to task due dates, key dates, and Form Builder date fields that use the displayFormat attribute.

Configure the date format in a list view

1. In the burger menu of the list view, select Manage this list view, then select Columns. The Customise columns blade opens.
2. Select the date column, select Custom format and enter the format, for example to override the default dd/MM/yyyy.
   
3. The column then displays in the custom format.
   

Remove the time zone indicator

The globe icon displays only in a column whose Formatter includes time zone handling, for example Date with lag status and time zone. To remove the globe icon from a column, set its Formatter to Date or Date with lag status.

A generated document has no viewing user, so the time zone on a user's profile does not apply. Dates in a document use the time zone of the date itself, or the work item time zone.

UTC and local values

In the Context Browser of Data Composer, date fields have two values:

• UTC: the value that Clio Operate stores.
• Local: the value converted to a time zone. Clio Operate uses the date's own time zone where it has one, for example on a task due date or an appointment. Otherwise it uses the work item time zone.

Use Local in document templates. The UTC value can display the previous day, for example on a date-only key date or during British Summer Time.

The Local value has a Value, which is the date and time, and a Time Zone, which is the time zone that Clio Operate used. To format the date, add a format query to the value in the path. For example:

workitem.lastClosedTransition.transitionDate.local.value!q?format=d+MMMM+yyyy

Format queries in Data Composer use .NET format codes, for example dd/MM/yyyy.

Dates with a UTC value only

Some dates have a UTC value only, for example the Created Date of a work item. Form Builder date and time fields also have no time zone of their own.

To display one of these dates in a particular time zone, convert it with the toLocalDateTime function in a tag expression. Give the time zone as an IANA time zone ID, for example:

toLocalDateTime(myDate, 'Australia/Melbourne').format('dd/MM/yyyy HH:mm')

For a date stored as 11pm UTC on 13 May 2026, this example returns 14/05/2026 09:00. If the time zone ID is not valid, the function returns the date unchanged. For the list of IANA IDs, see List of tz database time zones.

Set the default currency in Global Features > Currency.

Clio Operate handles multiple currencies and maintains a list of currencies in use. A single matter cannot hold a mix of transactions in different currencies. One matter can be Euro and another matter Sterling, but a single matter cannot mix currencies.

Every matter has an allocated currency. Where no currency is specified, the matter uses the default currency for that database.

Currency fields on Form Builder forms

A currency field on a Form Builder form uses the currency of the work item. Where the work item has none, it uses the currency of its nearest ancestor, then the default set in the Currency global feature.

To override this on a specific field, add the overrideCurrencyCode attribute with the relevant ISO 4217 currency code.

"overrideCurrencyCode": "USD"

The field then displays and returns values in US dollars.

See Configuring Multi Currency for full details.

Date Calculations workflow action

The Date calculations workflow action sits in the Data section of the Toolbox.

The calculation begins with either a predefined start date or a default of today’s date and time. Set the start date using now, or reference a date held in a variable.

Clio Operate then adds or subtracts an interval period. The resulting end date depends on the interval period entered and the Calculation unit selected. Set the interval period manually or pass it via a variable.

The two key Calculation unit values are Days and Working Days.

• Days. Clio Operate adds the number of interval days to the start date. Weekends and public holidays are ignored.
• Working Days. Clio Operate first references the Working Day Calendar of the user who triggered the workflow, or of that user's primary team. Where there is no user, for example on a scheduled trigger, it uses the system calendar. It totals all non-working days from that calendar that fall within the interval period, adds those non-working days to the days specified in the interval period to give the total number of calendar days, then adds that total to the start date, excluding weekends.

Worked examples:

• A 10 working day delay from Monday 1 April gives a due date two weeks later, Monday 15 April.
• A 10 working day delay from Monday 1 April, where a public holiday falls within those two weeks, gives a due date of Tuesday 16 April. Clio Operate counts the public holiday as a non-working day wherever it falls in the period, even where it does not fall on the due date itself.

The Court Days Calculator is an IDE plug-in that addresses the limitations of the standard Working Days calculation, specifically the behaviour of due dates that fall on a weekend or public holiday. Install it on demand.

Once installed, the Court Dates Calculator workflow action is available in the Visual Workflow Toolbox.

Start date

Set the Start Date using either today’s date or a variable passed into the action.

The Increment by value must be passed via a variable. One approach is to use the Default value parameter for the delay period variable.

Working days

Clio Operate references the Working Days Calendar of the current user to obtain non-working days such as public holidays. Unlike the standard Working Days behaviour, it does not count all working days within the period. The parameters below set the behaviour.

The examples that follow add 10 working days to Monday 1 December 2025 to set a first review date from an equity valuation date.

• If start date is weekend

• If start date is Bank Holiday
  This setting works in conjunction with the weekend setting above. 
  • Where the Monday is a bank holiday, Move to next working day moves the start date to Tuesday 2 December.
  • This applies whether the start date fell on a Monday originally, or moved to the Monday through the weekend setting.
  • Where the start date was originally a Saturday or Sunday, Move to the previous working day is selected, and the Friday is a bank holiday, the start date moves back to Thursday 27 November.
• If end date is weekend
  The rules above establish the end date, which is when the date falls due. The same logic then applies to that end date.

• If end date is Bank Holiday
  • Where the Monday is a bank holiday, Move to next working day moves the end date to Tuesday 16 December.
  • This applies whether the end date fell on a Monday originally, or moved to the Monday through the weekend setting.
  • Where the end date was originally a Saturday or Sunday, Move to the previous working day is selected, and the Friday is a bank holiday, the end date moves back to Thursday.
• If Bank Holiday is in period

Worked example: 

Add 10 working days to Monday 15 December, treating public holidays in the period as non-working days. Christmas Day and Boxing Day are classed as non-working days in the user’s Working Day Calendar.

Monday 15 December plus 10 working days is Monday 29 December. Because If Bank Holiday is in period is set to Non-Working Day, Clio Operate adds the two public holidays to the total, giving 31 December.

The calculated due date of 31 December after the two public holidays are added to the total

Where the end date falls on 1 January, use the end date settings to reschedule it. Move to the previous working day gives 31 December. Move to next working day gives 2 January.

Override output time

All dates output by the calculator have a due time of 7am. Use Override Output Time to amend this default.

Working months

A working month is a fixed 30 day period, not a period based on working days. 1 July plus one working month is 31 July.

The start and end date settings apply, with the exception of If Bank Holiday is in period. A Sunday start date can move forward to the Monday. Where the Monday is a public holiday, it can move forward again to the Tuesday. Clio Operate can also reschedule an end date that falls on a bank holiday or weekend to the next or previous working day.

Calendar days

Calendar Days are elapsed days. Clio Operate ignores non-working days. Monday 1 December plus 10 days is Thursday 11 December.

The If start date is weekend and If end date is weekend settings still apply. With If end date is weekend set to Move to Next Working Day, Wednesday 3 December plus 10 calendar days gives Saturday 13 December, which then moves forward to Monday 15 December.

Calendar months

The end date falls on the same day of the following month. 1 July plus one calendar month is 1 August. Clio Operate ignores non-working days.

The If start date is weekend and If end date is weekend settings still apply. With If start date is weekend set to Move to Next Working Day, Saturday 5 July plus one calendar month is Thursday 7 August. The start date moves forward to Monday 7 July, then Clio Operate adds a calendar month.