Expand my Community achievements bar.

Don’t miss the Workfront AMA: System Smarts & Strategic Starts! Ask your questions about keeping Workfront running smoothly, planning enhancements, reporting, or adoption, and get practical insights from Adobe experts.

Time Zone Alignment for Journal Entry Report Date Values

Avatar

Level 4

10/21/25

This idea proposal addresses a critical data integrity and reporting inconsistency in the existing Journal Entry Report related to Date custom fields. The report currently fails to correctly apply the user's time zone offset, resulting in dates that are one day off from the actual user-entered value displayed elsewhere in the platform.

 

Description - The "New Date Value" column in a Journal Entry Report tracking edits to a Date-Only custom field (i.e., not a Date/Time field) often displays an incorrect date. This date is shifted by the user's UTC offset, resulting in a day mismatch compared to the date displayed in the Custom Form and the System Activity Log. This inconsistency arises because the report is not correctly translating the stored UTC date (which defaults to 12:00 AM UTC) into the viewing user's local time zone, causing the date to prematurely roll over to the previous day.

 

Why is this feature important to you - 

Accurate reporting is fundamental to trusting a work management system. When a foundational report displays data that contradicts what's seen on the project itself and in the official activity log, it severely erodes user confidence and creates significant administrative overhead.

  1. Data Integrity and Trust: Contradictory dates force our teams to manually verify every data change, slowing down audits and governance processes. We need a single, reliable source of truth.

  2. Administrative Burden: The current workaround involves manually adding a text mode expression (ADDDAYS({}, 1)) to every single report column for every relevant Date field. This is not a sustainable or scalable long-term solution.

  3. Risk of Error: A manual offset workaround is fragile. It will break if users in other time zones view the report or if local time zone rules change (e.g., Daylight Saving Time shifts), introducing a high risk of new reporting errors.

This is a request to fix a systemic design flaw (as acknowledged in support feedback) that prevents the Journal Entry Report from displaying the correct user-entered date consistently across the platform.

 

How would you like the feature to work - 

The Journal Entry Report must be updated to apply the user's time zone offset to Date-Only custom field values consistently.

Specifically:

  • The date displayed in the "New Date Value" column must exactly match the date the user entered on the Custom Form and the date recorded in the System Activity Log.

  • The system logic for the Journal Entry Report should be aligned with the logic used by the Project Custom Forms and the System Activity Log when displaying Date-Only custom fields, ensuring all three views show the same, correct local date.

  • This fix should be system-wide and automatic, requiring no text mode workarounds or manual configuration changes by administrators for any Journal Entry Report.

 

Current Behaviour - 

When a user in a time zone with a negative UTC offset (e.g., Central Standard Time, UTC-6) enters a date (e.g., 10/30/25) into a Date-Only custom field:

  • Custom Form: Displays the correct user-entered date (10/30/25).

  • System Activity Log: Records and displays the correct user-entered date (10/30/25).

  • Journal Entry Report (in "New Date Value" column): Incorrectly displays the date as the UTC-adjusted date (10/29/25), shifting the date by one day due to the 12:00 AM UTC default crossing the day boundary in the user's local time zone.