2 examples
Hardcoded timestamp
Explicit timestamp coded, causing incorrect date/time data.
[ FAQ1 ]
What is a hardcoded timestamp?
A hardcoded timestamp is a fixed date or time value written directly into application code, rather than being dynamically generated at runtime. Developers might use hardcoded timestamps temporarily for testing or debugging purposes, but if left in production code, these timestamps can cause incorrect behavior, logic errors, or flaky tests as real-world time progresses. For example, code relying on a fixed timestamp might incorrectly handle date-sensitive logic or fail to accommodate time-based scenarios. Hardcoded timestamps lead to maintainability challenges, test instability, and unreliable application behavior.
[ FAQ2 ]
How to replace hardcoded timestamps in code
To replace hardcoded timestamps, use dynamic functions like
Date.now() or appropriate libraries to generate timestamps at runtime based on actual system time or configuration settings. For testing scenarios, leverage time-mocking libraries or frameworks that simulate and control timestamps reliably, ensuring tests remain stable and predictable. Clearly separate test-specific time values from production logic, utilizing dependency injection or configurable time sources. Regularly review and audit code for embedded date values, proactively removing hardcoded timestamps to ensure accurate and maintainable application logic.
diff block
greptile
style: Consider extracting the hardcoded timestamp 1628099186 into a named constant for better maintainability
suggested fix
pub fn is_active(&self, timestamp: &u32) -> bool {
+ const INITIAL_GUARDIAN_SET_CREATION_TIME: u32 = 1628099186;
// Note: This is a fix for Wormhole on mainnet. The initial guardian set was never expired
// so we block it here.
+ if self.index == 0 && self.creation_time == INITIAL_GUARDIAN_SET_CREATION_TIME {
false
} else {
self.expiration_time == 0 || self.expiration_time >= *timestamp
}