Skip to content

Conversation

@grzesir
Copy link
Contributor

@grzesir grzesir commented Nov 2, 2025

No description provided.

@korbit-ai
Copy link
Contributor

korbit-ai bot commented Nov 2, 2025

I was unable to write a description for this pull request. This could be because I only found files I can't scan.

Copy link
Contributor

@korbit-ai korbit-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review by Korbit AI

Korbit automatically attempts to detect when you fix issues in new commits.
Category Issue Status
Performance Timezone comparison using object identity ▹ view
Performance Redundant datetime normalization calls ▹ view
Functionality Static method called with instance/class reference ▹ view
Documentation Incomplete function docstring ▹ view
Files scanned
File Path Reviewed
lumibot/strategies/_strategy.py

Explore our documentation to understand the languages and file types we support and the files we ignore.

Check out our docs on how you can make Korbit work best for you and your team.

Loving Korbit!? Share us on LinkedIn Reddit and X

Comment on lines 133 to 135
tzinfo = getattr(aware, "tzinfo", None)
if tzinfo is not None and tzinfo != LUMIBOT_DEFAULT_PYTZ:
return aware.astimezone(LUMIBOT_DEFAULT_PYTZ)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Timezone comparison using object identity category Performance

Tell me more
What is the issue?

The timezone comparison uses object identity (!=) instead of timezone equality, which may fail when comparing equivalent timezone objects that are different instances.

Why this matters

This could cause unnecessary timezone conversions or missed conversions when timezone objects represent the same timezone but are different instances, leading to incorrect datetime handling in backtests.

Suggested change ∙ Feature Preview

Use timezone equality comparison or zone name comparison instead of object identity:

if tzinfo is not None and str(tzinfo) != str(LUMIBOT_DEFAULT_PYTZ):
    return aware.astimezone(LUMIBOT_DEFAULT_PYTZ)

Or use timezone zone comparison if available.

Provide feedback to improve future suggestions

Nice Catch Incorrect Not in Scope Not in coding standard Other

💬 Looking for more details? Reply to this comment to chat with Korbit.

Comment on lines +1406 to +1407
backtesting_start = self._normalize_backtest_datetime(backtesting_start)
backtesting_end = self._normalize_backtest_datetime(backtesting_end)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redundant datetime normalization calls category Performance

Tell me more
What is the issue?

The datetime normalization is called twice for the same values - once in run_backtest and again in verify_backtest_inputs, causing redundant timezone conversion operations.

Why this matters

This creates unnecessary computational overhead by performing the same timezone conversion operations multiple times, which could impact performance especially when running many backtests.

Suggested change ∙ Feature Preview

Pass the already normalized datetime objects to verify_backtest_inputs or modify verify_backtest_inputs to accept pre-normalized datetimes:

self.verify_backtest_inputs(backtesting_start, backtesting_end, already_normalized=True)

And update verify_backtest_inputs to skip normalization when already_normalized=True.

Provide feedback to improve future suggestions

Nice Catch Incorrect Not in Scope Not in coding standard Other

💬 Looking for more details? Reply to this comment to chat with Korbit.

Comment on lines 127 to 136
@staticmethod
def _normalize_backtest_datetime(value):
"""Convert backtest boundary datetimes to the LumiBot default timezone."""
if value is None:
return None
aware = to_datetime_aware(value)
tzinfo = getattr(aware, "tzinfo", None)
if tzinfo is not None and tzinfo != LUMIBOT_DEFAULT_PYTZ:
return aware.astimezone(LUMIBOT_DEFAULT_PYTZ)
return aware
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Static method called with instance/class reference category Functionality

Tell me more
What is the issue?

The static method _normalize_backtest_datetime cannot access class or instance attributes, but it's being called as self._normalize_backtest_datetime() and cls._normalize_backtest_datetime() in the code.

Why this matters

Static methods don't have access to self or cls, so calling them with instance or class references can lead to confusion and potential issues if the method ever needs to access class/instance state. The method should either be a classmethod if it needs class access, or the calls should use the class name directly.

Suggested change ∙ Feature Preview

Change the static method to a classmethod since it's being called with cls reference:

@classmethod
def _normalize_backtest_datetime(cls, value):
    """Convert backtest boundary datetimes to the LumiBot default timezone."""
    if value is None:
        return None
    aware = to_datetime_aware(value)
    tzinfo = getattr(aware, "tzinfo", None)
    if tzinfo is not None and tzinfo != LUMIBOT_DEFAULT_PYTZ:
        return aware.astimezone(LUMIBOT_DEFAULT_PYTZ)
    return aware
Provide feedback to improve future suggestions

Nice Catch Incorrect Not in Scope Not in coding standard Other

💬 Looking for more details? Reply to this comment to chat with Korbit.

Comment on lines 128 to 129
def _normalize_backtest_datetime(value):
"""Convert backtest boundary datetimes to the LumiBot default timezone."""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Incomplete function docstring category Documentation

Tell me more
What is the issue?

The docstring only states what the function does but lacks parameter and return value documentation.

Why this matters

Without parameter and return value documentation, users won't know what type of input is expected or what type of output is returned.

Suggested change ∙ Feature Preview

"""Convert backtest boundary datetimes to the LumiBot default timezone.

    Parameters
    ----------
    value : datetime or None
        The datetime value to normalize

    Returns
    -------
    datetime or None
        The normalized datetime in LUMIBOT_DEFAULT_PYTZ timezone"""
Provide feedback to improve future suggestions

Nice Catch Incorrect Not in Scope Not in coding standard Other

💬 Looking for more details? Reply to this comment to chat with Korbit.

@grzesir grzesir merged commit 940a61b into dev Nov 2, 2025
1 check failed
@korbit-ai
Copy link
Contributor

korbit-ai bot commented Nov 2, 2025

I was unable to write a description for this pull request. This could be because I only found files I can't scan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants