When users export data to CSV from Clarity MUX list pages (Projects, Tasks, Status Reports, Hierarchies, or sub-grids), the exported file displays dates in a format that does not match the user's configured locale.
Specifically:
The behavior is consistent across all users regardless of their locale setting and affects all list pages that offer the Export to CSV option.
Clarity 16.4.1,16.4.2
The "Export to CSV" action in Clarity MUX triggers a server-side asynchronous job (CSV_EXPORT_ITEMS) that calls the REST API internally and writes the response to a CSV file. The date formatting logic in this job uses a hardcoded date format and does not consult the user's locale or the formatting locale from the user's security context.
In Clarity 16.2.0 and earlier: The CSV export engine did not explicitly specify a date format locale when generating output, causing the application server to fall back to its default locale — which is US English (en_US) on most server deployments. This results in dates being written in M/d/yyyy format (for example, 4/1/2026), without zero-padding for the month or day.
In Clarity 16.4.x or higher: The format is explicitly hardcoded to yyyy-MM-dd (ISO 8601). This is uniform across all users regardless of locale.
The user's language/locale preference in their Clarity profile (English (United Kingdom) or any other locale) controls how dates are rendered in the Clarity MUX interface, but has no effect on the date format written into exported CSV files.
There is no configuration setting — at the admin level or user level — that changes the date format in CSV exports from Clarity MUX. This is by-design behavior.
Short-term workaround: After exporting, reformat the date column in the CSV file before distributing to end users.
Common options:
Raise an Enhancement Request through the Clarity Idea Portal requesting locale-aware date formatting in Clarity MUX CSV exports. Include the number of affected users and any regulatory or reporting requirements to support prioritization.