Skip to content

Add VWAP Quarterly and Yearly periods#77

Open
robertotena wants to merge 1 commit into
AtasPlatform:Developfrom
robertotena:vwap-add-yearly-quarterly
Open

Add VWAP Quarterly and Yearly periods#77
robertotena wants to merge 1 commit into
AtasPlatform:Developfrom
robertotena:vwap-add-yearly-quarterly

Conversation

@robertotena
Copy link
Copy Markdown

@robertotena robertotena commented Jul 15, 2025

Added VWAP yearly and quarterly periods

@robertotena robertotena changed the title Add Quarterly and Yearly periods Add VWAP Quarterly and Yearly periods Jul 15, 2025
@Stig4all
Copy link
Copy Markdown
Collaborator

Thanks for the contribution. Adding quarterly and yearly VWAP periods is a reasonable feature request and fits the existing indicator well.

That said, I think the implementation needs one more pass before merge. Weekly and monthly logic in this codebase already relies on existing period/session-aware helpers, while this PR introduces new quarter/year boundaries with separate local logic. I am not yet confident that the new behavior will stay fully consistent with session handling and the rest of the indicator's reset rules.

The feature itself makes sense, but I would prefer to see the implementation rebased onto the current code and validated against the existing session model before merging.

@robertotena robertotena force-pushed the vwap-add-yearly-quarterly branch from de46096 to 55f5ecf Compare April 13, 2026 13:26
@robertotena
Copy link
Copy Markdown
Author

Ah good to know! I have just rebased :) And how could I do that validation? Could you please point me to an example so I can see how it is done? I added those 2 methods to mimic what I think there was in the base class, but I did not find the code for it either

@Stig4all
Copy link
Copy Markdown
Collaborator

The validation I had in mind is mostly behavioral validation against the existing period logic, rather than a separate test framework.

A few pointers from this repo:

  • DailyLines is a good example of how weekly boundaries are adapted when custom session logic is involved. It wraps the inherited method and then delays the boundary until the bar is actually inside the session:
    Technical/DailyLines.cs, around IsNewWeek(...).

  • Pivots is another useful reference. It keeps the standard IsNewWeek() / IsNewMonth() behavior, but when custom session mode is enabled it adds its own custom wrappers:
    Technical/Pivots.cs, around IsNewCusomWeek(...) and IsNewCusomMonth(...).

So the concern is not that your IsNewQuarter() / IsNewYear() methods are “wrong” by themselves. It is more that Weekly and Monthly in this codebase already rely on inherited/session-aware logic, while Quarterly and Yearly are currently implemented as direct calendar checks. That is why I suggested validating them carefully.

Also, the reason you probably could not find the original implementation is that IsNewWeek() / IsNewMonth() are not implemented in this repository. They are inherited from the SDK base class / referenced assemblies, so we only see how this repo uses or wraps them.

What I would validate manually:

  1. ShowFirstPeriod = false and confirm the indicator starts exactly at the first bar of a new quarter/year.
  2. Check boundaries around:
    • Mar -> Apr
    • Jun -> Jul
    • Sep -> Oct
    • Dec -> Jan
  3. Check instruments/sessions where the first trading bar of the new quarter/year is not exactly at midnight or calendar open.
  4. Compare behavior with existing Weekly / Monthly handling and verify the reset feels consistent with the current session model.

So in short: I think your implementation is a reasonable first step, but I would be more comfortable merging it after confirming that the reset behavior is consistent with how this project already handles session-aware periods.

@AlbertoAmadorBelchistim
Copy link
Copy Markdown
Contributor

Hi @robertotena , jumping in as another contributor. I think the reviewer's concern boils down to: IsNewWeek() / IsNewMonth() (inherited from the SDK base) are session-aware, so on Globex futures or any instrument where the session crosses midnight they fire at the start of the relevant session, not at calendar midnight. Your IsNewQuarter() / IsNewYear() compare GetCandle(bar).Time directly, which can land on a different bar for the same boundary - that's the inconsistency the reviewer is asking you to validate.

A minimal way to inherit that session-awareness for free is to delegate to IsNewMonth(bar) and just filter by month number - same pattern Pivots uses for its custom wrappers. Something like:

private bool IsNewQuarter(int bar)
{
    if (!IsNewMonth(bar)) return false;
    var month = GetCandle(bar).Time.Month;
    return month == 1 || month == 4 || month == 7 || month == 10;
}

private bool IsNewYear(int bar)
{
    if (!IsNewMonth(bar)) return false;
    return GetCandle(bar).Time.Month == 1;
}

Feel free to take it as-is, tweak it, or go a different way - just sharing in case it unblocks the PR. Happy to help further if you want.

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.

3 participants