This is worth a longer conversation to understand and consider. Let's continue discussing here:

• Use of standard vs. timezone-aware `date` types DaveSkender/Stock.Indicators#1306

I've left some initial thoughts there.

Try normalizing your dates to UTC format with .astimezone(timezone.utc).

from stock_indicators.indicators.common.quote import Quote
from decimal import Decimal
from datetime import datetime, timezone

dt = datetime.fromisoformat('2000-03-26 23:00+0000')
print(str(dt.tzinfo))  # UTC
print(str(dt.time()))  # 23:00:00

# Ensure the datetime retains its timezone information
q = Quote(
    date=datetime.fromisoformat('2000-03-26 23:00+0000').astimezone(timezone.utc),
    open=Decimal('23'),
    high=Decimal('26'),
    low=Decimal('20'),
    close=Decimal('25'),
    volume=Decimal('323')
)

print(str(q.date.tzinfo))  # UTC
print(str(q.date.time()))  # 23:00:00

Try normalizing your dates to UTC format with .astimezone(timezone.utc).

@DaveSkender As you probably found out yourself, this fix doesn't work, but you already created a PR that fixes that, so THANK YOU! 🙂

As you probably found out yourself, this fix doesn't work, but you already created a PR that fixes that, so THANK YOU! 🙂

So far, that experimental PR (#410) isn't working either. Date handling strategy is almost always a game of trade-offs since there are so many inconsistencies across ecosystems and languages. I'm not entirely sure yet that we'll be able to handle every situation internal to the library yet -- just experimenting for now.