Best practices for configuring multi-site Gantt chart views across time zones

Our organization manages projects across manufacturing sites in three different time zones (EST, CET, and JST). We’re using Aras 12.0 Project Management and struggling with how to best configure Gantt chart views so teams see schedules in their local time while maintaining accurate dependencies.

Currently, all our project schedules display in UTC, which causes confusion during daily standups. Engineers in Japan see task start times as 9:00 when they actually mean 18:00 local time. The Gantt chart customization options seem limited for time zone handling. We’ve tried setting user preferences for time zones, but the Gantt view doesn’t respect those settings consistently.

Multi-site scheduling becomes problematic when tasks span locations - a dependency from Japan to Germany shows overlapping work hours that don’t actually exist. Has anyone successfully configured Gantt charts for global teams? What’s the recommended approach for time zone configuration in multi-site projects?

Recommendation

The core issue is that Aras Innovator’s Project Management module stores all datetime values in UTC internally, and the standard Gantt chart rendering in 12.0 does not automatically localize display times per user. The recommended approach combines server-side user locale configuration, a client-side presentation layer fix, and a dependency modeling discipline.

1. Enforce time zone at the User item level, not just preferences. Navigate to Administration → Users and confirm each user’s time_zone property is explicitly set (e.g., America/New_York, Europe/Berlin, Asia/Tokyo). The Gantt widget reads this property at render time — if it is null, it falls back to server time zone, which is likely UTC. Verify in your version whether 12.0 SP levels affect this fallback behavior; patch levels from SP4+ reportedly improved consistency here.

2. Apply a Method-based time zone offset on the Gantt datasource query. Rather than relying on the presentation layer alone, offset datetime values before they reach the chart. Override the GetProjectItems server Method to apply a UTC offset based on the requesting user’s time_zone property. This ensures the Gantt receives pre-adjusted values.

// Simplified AML fragment within a server-side Method
var tz = this.getPropertyValue("time_zone"); // from current user item
// Apply offset logic before returning project task datetimes

3. Model cross-site dependencies with explicit lag time. For EST→JST handoffs, use Finish-to-Start with lag equal to the non-overlapping gap between work calendars. Define separate Work Calendars per site under Project → Calendars, assign tasks to site-specific calendars, and let the scheduler calculate realistic start windows. This eliminates the phantom overlap problem.

4. Create role-specific Gantt views using saved searches. Use ItemTypes → saved searches to scope each site’s default view to their calendar and filter out off-shift dependencies from the primary display. Teams then see only actionable tasks without cross-timezone noise cluttering standups.


Common Mistakes

  • Setting time zone in Personal Preferences UI only — this does not reliably propagate to the Gantt widget in 12.0.
  • Using a single global Work Calendar — this is the primary cause of phantom overlapping dependency windows.
  • Storing task notes with local times as freetext — creates documentation drift when engineers in different regions interpret the same note differently.
  • Customizing the Gantt presentation layer via XSLT without adjusting the underlying AML query — offset must happen at the data layer, not the display layer.

Version-Specific Note

Aras 12.0 Gantt functionality is built on a third-party charting library that has limited native time zone awareness — verify in your version whether any applied service packs include Gantt timezone patches before investing in Method-level overrides. In Aras 14+ (verify in your version), the rearchitected Project Management module provides improved locale-aware scheduling natively, which may reduce the need for custom Method overrides described above.


This draft is based on general Aras Innovator knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

We faced similar challenges with our EU-US projects. One approach is to standardize on a single reference time zone for all project planning (we use UTC) but add custom properties to tasks for ‘Local Start Time’ and ‘Local End Time’. You can populate these automatically with a server event that converts based on the assigned resource’s location. Not perfect, but helps with communication.

The Gantt control in Aras 12.0 has limited native time zone support. However, you can customize the view using the Gantt Configuration ItemType. Create different configurations for each region with adjusted display offsets. Then use conditional logic in your project forms to load the appropriate configuration based on the current user’s location property. It’s not automatic per-user time zone conversion, but it gives each site a view that makes sense for their planning meetings.

The custom property approach might work for reporting, but I’m concerned about the Gantt chart itself - when someone drags a task bar to reschedule, will it calculate correctly? Also, how do you handle dependencies between sites? If a Tokyo task must finish before a Berlin task starts, the Gantt should show the actual time gap, not just the UTC hours.

For dependencies across time zones, we implemented a validation method that calculates effective working hours overlap. When a user creates a cross-site dependency, the system checks if there’s actual collaboration time available. For example, Tokyo (JST) and Berlin (CET) have about 1-2 hours of overlap. We flag dependencies that require real-time collaboration outside those windows and suggest asynchronous handoff patterns instead. This doesn’t solve the Gantt display issue but prevents unrealistic schedules.

Consider whether you actually need real-time time zone conversion in the Gantt or if you need better working hours modeling. We use a ‘Follow-the-Sun’ scheduling approach where tasks are scheduled in 8-hour blocks aligned to site working hours. Each site has a defined work calendar in Aras with their local business hours. The Gantt shows UTC times, but we train teams to think in ‘work shifts’ rather than clock times. Documentation includes a conversion reference chart for each site pairing.

After implementing multi-site project management for several global manufacturers, here’s what works best:

Time Zone Configuration Strategy: Accept that Aras 12.0’s Gantt won’t do automatic per-user time zone display. Instead, implement a hybrid approach. Configure your system to store all dates in UTC (this is standard), but enhance the UI with time zone awareness. Add a custom property to the Project ItemType called ‘Primary Time Zone’ that defaults to the project manager’s location. This becomes the reference time zone for all Gantt displays for that project.

Multi-Site Scheduling Approach: Create site-specific work calendars that define actual working hours in UTC. For example, Tokyo working hours (9am-6pm JST) become 0:00-9:00 UTC. When the scheduling engine calculates task durations and dependencies, it uses these UTC-based calendars. This ensures dependencies respect actual working hours. Your Tokyo-to-Berlin dependency will automatically show the overnight gap because Berlin’s calendar doesn’t start until 7:00 UTC.

Gantt Chart Customization: Extend the Gantt view with a custom toolbar that shows multiple time zone clocks. Users select which zones to display, and the toolbar shows current time in each zone plus visual indicators of working/non-working hours. While the Gantt bars themselves remain in the project’s primary time zone, this context helps users understand cross-site timing.

Practical Implementation Tips:

  • Use color coding: tasks assigned to Tokyo resources appear in one color, Berlin in another
  • Add tooltips to task bars showing local start/end times for the assigned resource
  • Create a ‘Time Zone Impact’ report that highlights dependencies spanning more than 6 hours difference
  • Train teams to schedule handoffs at ‘boundary times’ - end of day for one site, start of day for the next

The key insight is that perfect time zone visualization is less important than ensuring the scheduling engine respects working hours. Focus your customization effort on accurate calendar configuration and clear visual indicators of site assignments rather than trying to make the Gantt dynamically convert times per user.