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

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.
  
• Clio Operate can also be configured to look up the work type hierarchy and reference the work item time zone specified on an ancestor, such as a Statement of Work.
• A user profile time zone overrides what that individual sees. A user based in Copenhagen sets UTC +1 on their profile and sees times converted to Copenhagen local time.
  
• Where the user time zone differs from the work item time zone, Clio Operate displays a globe icon. Hovering over the icon displays the date and time in 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.

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 an ancestor work type where configured.
• Where the user time zone and the work item time zone differ, a globe icon appears next to the key date. Hovering over it displays the date and time in the work item 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, but the hint now displays the date and time relative to Singapore.

The fee earner moves to the Singapore office and sets their profile time zone to Singapore. The key date displays in Singapore local time, and the globe icon disappears because the user time zone and work item time zone match.

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 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 work item time zone, a globe icon appears. Hovering over it displays the work item due date and time.
• 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.

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 the plus icon 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.

An appointment sits under the task hierarchy, so its work item time zone is inherited from Global Features > Regional Settings.

An aspect on the Appointments blade allows the time zone to be amended where required.

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.

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. Open the List View Columns configuration for the list view.
2. Apply a Custom Format to the date column, for example to override the default dd/MM/yyyy.
   
3. The column then displays in the custom format.
   

Remove the time zone indicator

The same configuration holds a Time Zone status setting. Remove the status and the globe icon no longer appears against dates in that column.

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 default currency set in Global Features.

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 Calculation 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 Days Calendar selected on the current user’s profile. 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.