[Feature] Date handling architecture clarification for multi-regional usage

[Elmino-19]

Target Module

General (cross-module)

Description

Clarify and support a consistent architecture for user-facing date input and display to enable usage in multi-regional organizations with different calendar systems, without changing backend storage or business logic.

Use Case

Organizations operating in multiple countries use different calendar systems. Currently, unclear date handling across models, forms, templates, and frontend JS makes it difficult to localize date input and display without unintended side effects, limiting adoption in such environments.

Proposed Solution

Document and/or introduce clear extension points for:

date entry (forms/serializers),

date display (templates or JS),

frontend date inputs,
while keeping all internal storage Gregorian.

Benefits

Enables multi-regional and international adoption

Improves maintainability and extensibility

Reduces risk of unintended side effects when customizing dates

Keeps core logic and database unchanged

Additional Information

No response

Labels

enhancement

Priority

Medium

Assignees

No response

Related Issues

No response

Submission Checklist

• I have searched for duplicate feature requests
• I have provided clear and concise information

[horilla-opensource]

Hi @Elmino-19,

Thank you for opening this feature request and for clearly outlining the architectural concern. This is a very valid point, especially for multi-regional organizations 👍

Current Architecture Overview

At present:

• Storage: All dates are stored in standard Gregorian format using Django DateField / DateTimeField.

• Display formatting: Controlled via Horilla → Settings → Date & Time Format, saved at the Company level.

• Frontend formatting: Handled through date_formatting.js and time_formatting.js, which:

  • Fetch company format
  • Cache in localStorage
  • Use moment.js for rendering

Backend storage and business logic remain unchanged and ISO/Gregorian-based.

Extension Points (Safe to Customize)

To support multi-regional use cases while keeping storage intact, the following areas are safe and recommended for extension:

Date Entry (Forms)

Dates are primarily entered through Django ModelForm.

You can safely extend:

base > form.py
class ModelForm(forms.ModelForm)

This is the cleanest global hook for:

• Custom widgets
• Custom input formats
• Pre-submit conversion to Gregorian

This keeps changes centralized and reversible.

Date Display

Display is mostly handled at the frontend level.

Safe extension areas:

• date_formatting.js
• time_formatting.js
• Template-level formatting filters

You can introduce:

• Per-user formatting
• Locale-based logic
• Calendar conversion before rendering

Without touching database structure.

Frontend Date Inputs

Currently, date inputs are not fully abstracted into a centralized date component.

A future improvement (aligned with your suggestion) would be:

• Introducing a unified date input wrapper
• Standardizing frontend date picker initialization
• Documenting a clear override pattern

We agree this would improve extensibility.

Non-Gregorian Calendar Support

Currently:

• Not natively supported.
• System assumes Gregorian storage.

Recommended approach (safe and maintainable):

• Convert to non-Gregorian in UI layer
• Convert back to Gregorian before form submission
• Keep backend fully Gregorian

This keeps business logic untouched and avoids migration complexity.

We will keep this feature request open as an enhancement for architectural clarity and extensibility improvements.

Thank you again for raising this thoughtfully — it’s feedback like this that helps make Horilla more production-ready for global use

Best Regards,
Team Horilla