Use of standard vs. timezone-aware date types

[DaveSkender]

A user raised a valid point about needing timezone awareness or offsets. I appreciate the opportunity to discuss further and to get community feedback. Let me explain the current approach of using the simpler form of DateTime and the rationale behind it.

Why we use plain datetime data types

1. Industry norms: Financial market data is typically timestamped relative to the exchange's local timezone and rarely includes timezone offsets. For example:

   • NYSE and NASDAQ data is generally in U.S. Eastern Time without explicit offsets.
   • Many data feeds rely on users to know the context and handle any timezone normalization themselves.

   Given this, plain datetime objects align with the majority of use cases and data sources.

2. Performance and simplicity: timezone-aware types (e.g., DateTimeOffset in .NET or datetime with tzinfo in Python) add overhead in terms of size, computation, and complexity. For a performance-focused library, this trade-off is significant, especially when handling large datasets.

3. User-controlled normalization: The library assumes that users normalize data (e.g., to UTC) in their pre-processing pipelines. This keeps the library lightweight and focused on its core purpose—calculations and indicators.

Addressing concerns

We do recognize that timezone-aware dates could benefit use cases involving multiple exchanges or explicit timezone handling. However, introducing timezone support across the library would require careful consideration to avoid unintended side effects, such as increased memory usage, reduced performance, or breaking existing user workflows.

Possible Next Steps

• Community input: If you feel this feature would significantly enhance the library, let’s continue the conversation in this discussion. We’d love to understand more about your use cases and see if others in the community share this need.
• Custom extensions: One potential approach could be adding optional timezone support as an opt-in feature, where users explicitly enable it for their data. This would allow advanced use cases without impacting the majority of users.
• Documentation updates: To help users avoid unexpected behavior, we could improve documentation to emphasize that input datetime objects are treated as plain and recommend normalizing to UTC before passing them into the library.

Originally suggested by @goulashsoup in a bug report for our Python library

[goulashsoup]

The library assumes that users normalize data (e.g., to UTC) in their pre-processing pipelines.

That is a valid approach that not only keeps performance, but also unifies the usage of the library across projects: If we only allow UTC-times, there are no more questions and possible bugs because of different time zones.

@DaveSkender I also suggest to add a UTC timezone check to Quote and similar classes for the next major version...

[DaveSkender]

I see where you're coming from, but my point was more about emphasizing that timezone information is irrelevant when the library should simply passes through date-in/date-out without altering or interpreting it.

Requiring a specific timezone for all inputs might impose unnecessary constraints on users, especially when some workflows don't need timezone specifications at all.

For the issue you raised in your bug report, my focus is on ensuring the library doesn’t lose any date-related information, while keeping things as flexible and straightforward as possible for diverse use cases.