# NAgetSntpTime returns bogus time with good status

**URL:** https://forums.digi.com/t/nagetsntptime-returns-bogus-time-with-good-status/5862
**Category:** NET+OS
**Created:** [November 10, 2010, 7:27pm UTC](https://forums.digi.com/t/nagetsntptime-returns-bogus-time-with-good-status/5862 "2010-11-10T19:27:23Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![billr](https://avatars.discourse-cdn.com/v4/letter/b/ac8455/32.png) [@billr](https://forums.digi.com/u/billr)
#### Post date: [November 10, 2010, 7:27pm UTC](https://forums.digi.com/t/nagetsntptime-returns-bogus-time-with-good-status/5862/1 "2010-11-10T19:27:23Z")

</div>

We use the NAgetSntpTime() function to get the current time to synchronize a local RTC. In most cases this is working just fine, however in some cases, when deployed in the field, the value returned is equal (or close to - hard to tell for sure) the NTP epoch boundary in Feb 2036 but the status returned is NA\_SUCCESS. Has anyone seen this or have any idea what could be going on? This is with DigiOS 7.2. In all cases, the ntp server IPs are the same (hard coded).

---

<div class="post-metadata">

### Author: ![billr](https://avatars.discourse-cdn.com/v4/letter/b/ac8455/32.png) [@billr](https://forums.digi.com/u/billr)
#### Post date: [February 12, 2011, 8:38pm UTC](https://forums.digi.com/t/nagetsntptime-returns-bogus-time-with-good-status/5862/2 "2011-02-12T20:38:56Z")

</div>

This is a follow-up, in case anyone experiences this same problem. The Feb 2036 date is the epoch boundary for ntp servers. If ntp encounters an error while contacting a server, it may return the epoch date (max time value) as the result of a query. Since NAgetSntpTime() is actually getting a value back from its query, it returns NA\_SUCCESS.

As it turns out, the underlying problem was the ntp server in use was decommissioned and no longer valid, so ntp was getting an error when attempting to do the query.
