Future-Proofing Your Sharepoint Date Code For Maintainability

The Problem with Hardcoded Dates

Using explicit date values directly in code, known as hardcoded dates, leads to brittle systems that can easily break over time. As requirements change, values that seemed sensible during initial development may become invalid. Some examples of problematic hardcoded dates in SharePoint solutions:

• Restricting access to site collections based on a specific cutoff date, which stops working after that date passes
• Scheduling tasks and jobs using a hardcoded date that remains static, causing the tasks to run at the wrong times as time passes
• Filtering data based on dates that are explicitly specified, causing the filters to become useless over time

In all these cases, the code with hardcoded dates stops functioning correctly after some time passes. The dates become misleading, access restrictions fail open/closed, and scheduled operations run at the wrong intervals or fail to run entirely as the crossing of a hardcoded date can cause unanticipated logic flaws. Code that makes assumptions using temporal constants is inherently fragile.

Using Relative Dates for Robustness

To avoid issues with hardcoded dates, use relative dates in date logic instead. This involves calculating dates on the fly relative to the current date. For example:


// Hardcoded cutoff date
const cutoff = new Date('2023-12-31');

// Relative cutoff date
const cutoff = new Date();
cutoff.setFullYear(cutoff.getFullYear() + 1); // 1 year from now


By leveraging the current date and calculating relative values, the logic adapts automatically over time without breaking. Any datum that requires a temporal context, such as access control based on hire date, historical trend analysis, or task scheduling should rely on relative date calculations rather than hardcoding specific temporal constants.

Some key cases where this technique applies:

• Access restrictions based on tenure at a company
• Regular alerts for events, such as quarterly sales forecasts
• Scheduling future One Time Occurrences in SharePoint

Proper use of relative dates builds robustness against changes over time and prevents date-related logic errors.

Date Utilities for Abstraction

Beyond simply using relative dates, additional abstraction for date logic is highly beneficial. By encapsulating date calculations into reusable helper classes and modules, the main business logic remains clean, simple, and declarative.

Examples of useful date utilities:

• Date boundary calculators, ex: NextMonth(), DaysAgo()
• Date range generators, ex: PreviousNDays()
• Temporal predicates, ex: IsLastDayOfMonth()
• Date formatters, ex: ToIsoString(), ToSqlDate()

Well-designed date utilities handle complexity behind the scenes, while enabling straightforward date logic implementation:


// Business logic remains simple
const results = db.Query(
'SELECT * FROM events WHERE event_date > $1',
DateUtil.DaysAgo(30)
);


Encapsulating date manipulation into reusable modules/libraries abstracts away unnecessary complication and provides cleaner client code.

Testing Dates

Date logic is notoriously difficult to test properly due to its temporal nature. To correctly validate date code:

• Spy on calls to the system clock to simulate fixed dates during testing
• Stub out any calls to external services dependent on dates
• Use dependency injection to provide fake implementations of date utilities
• Generate date values across various ranges to validate calculations

With rigorous mocking, dates can be simulated programmatically for full test coverage:


// Mock current date
jest.spyOn(Date, 'now')
.mockReturnValue(new Date('2022-01-01').valueOf());

// Test date-based logic
expect(IsEligibleForHolidayBonus(employee))
.toBeTruthy();


By controlling time itself within tests, all temporal code paths can be exercised for confidence changes won’t break functionality.

Maintaining Dates Over Time

Even with the most robust date code, as years go by, legacy temporal logic can become outdated. Schedule periodic reviews of all date manipulation to address drift over time.

Some best practices:

• Logically group all date calculations into well-named modules or classes for simplified discovery and analysis
• Extract hardcoded temporal constants to config files for ease of updates
• Set calendar reminders to re-verify assumptions twice a year
• Prior to upgrades or migrations, audit date logic for needed updates

Proactive maintenance helps ensure systems don’t decay as requirements change. Continual refinement of temporal code ensures it remains accurate and relevant.

The Benefits of Future-Proofed Dates

Putting strict standards around date logic has multitude benefits:

• Robustness – With no hardcoded dates, relative calculations adapt automatically over time
• Reduced Bugs – Thorough date unit testing enables early identification of flaws
• Simplified Maintenance – Abstracted date utilities and segmented logic enables easy discoveries of areas needing updates
• Focus – With confidence date code won’t break, developers spend time on higher value work rather than perpetual bug fixes

By investing in temporal code quality, engineering teams build resilience against bit rot in key date logic. This results in stable, reliable systems requiring less reactive support over decades-long lifetimes. The high initial effort pays sustainable dividends long-term.