CFE TIME coverage test fails if set to use UTC #2393
Comments
jphickey
added a commit
that referenced
this issue
Jul 13, 2023
Setting this value to 0 allows it to get the same result regardless of the setting of CFE_MISSION_TIME_CFG_DEFAULT_UTC.
2 tasks
jphickey
added a commit
that referenced
this issue
Jul 14, 2023
Setting this value to 0 allows it to get the same result regardless of the setting of CFE_MISSION_TIME_CFG_DEFAULT_UTC.
This was referenced Jul 14, 2023
dzbaker
added a commit
that referenced
this issue
Jul 17, 2023
Fix #2393, set AtLeapSeconds in ExternalTone test case
dzbaker
added a commit
to nasa/cFS
that referenced
this issue
Jul 17, 2023
Fast-Tracked cFE Pull Request nasa/cFE#2398, nasa/cFE#2399, nasa/cFE#2404: Resolves nasa/cFE#2393, nasa/cFE#2395. Reverts nasa/cFE#2399
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When configuration is set to use UTC, the "ExternalTone" test case will fail.
To Reproduce
Configure
CFE_MISSION_TIME_CFG_DEFAULT_UTCto be true, then compile and run coverage tests.Expected behavior
The test should pass regardless of how this configuration item is set.
System observed on:
Debian
Additional context
This is because it adds leap seconds into the
NewSTCFvalue only when set to use UTC. The leap seconds were not configured by this test case, so it still has a value from a previous test case, which is 32. This larger-than-expected jump causes it to go into theCFE_TIME_OUT_OF_RANGEresult case.Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: