无法获得正确的Unix时间

它就像这个/ /参考时期使用。（默认值：01-JAN-1970 1970：00）定义旧的MLA中的NTPL历元（864万UL*（365UL*70UL+17UL）…希望这有帮助！



      以下为原文

    It was like this
 
// Reference Epoch to use.  (default: 01-Jan-1970 00:00:00)
#define NTP_EPOCH                 (86400ul * (365ul * 70ul + 17ul))
 
in old MLA...
hope this may help!

嗯，我只是开始调侃和谐V1.09和V2.02.00。也许我根本不应该评论，但是这个论坛只是我学到的唯一实用的地方。（也许有些专家可以插嘴。）我真的很感激！总之，这里是如何运行的（我想）：TCPIPPSNTPUTCUSESGET（）调用SysTyTMR.TICKCONGTGET（），它检索SysMyRoStubj.SysStukCube。现在…SysSimRoBjC.SysStkCube初始化为零（我想），而ySysStRMJARALCALLACK（）函数负责每秒更新它。你的程序，不知何故，在SysMsRojPoto.SyStCyCalk中存储了一个有意义的值，我想你会看到自从系统初始化以来已经经过的秒数。我正在实现一个UDP客户端应用程序，并且在我的工作站的端口17上有一个UDP时间服务器。（最终，这将与DHCP后台程序和专用UDP服务器上的专有UDP服务器一起运行。）的想法是，在启动时，PIC32从工作站获得UNIX时间（从1970年1月1日起经过的秒），并以此为基础在PIC32上进行一天中的时间。系统。我还没有到达那里，但这正是我的目标。我可以告诉你，使用公历计算，这是从1月1日到0000日到1月1日1970秒的时间。当然，这是胡说八道，因为我们没有在零年的1月1日（事实上，没有零年——想想吧！）因为在第十六到第十八个世纪的日历调整大大改变了事情。（“损失”了一大堆秒，等等）。但至少这是从格里高利日历计算出来的，如果我们从1月1日1970回来。我无法想象价值2208988800是如何或为什么有用的，但它确实存在。我也无法想象这个未被评论的“神奇数字”是某种宇宙巧合。（然而：请参阅脚注）我的意思是，有人有理由定义那个特定的常数。但是，仅仅因为有一个原因并不意味着这是一个很好的理由。我简直想不出这是不是一个好理由。DaveFootnote，



      以下为原文

   
 
Well, I'm just starting to poke around Harmony v1.09 and v2.02.00b.  Maybe I shouldn't comment at all, but this forum is just about the only place I learn anything practical, so here goes.  (Maybe some experts can chime in.  I would really, really appreciate it!)
 
Anyhow, here's how it goes (I think):
TCPIP_SNTP_UTCSecondsGet() calls SYS_TMR_TickCountGet(), which retrieves sSysTmrObject.sysTickCount.
Now...
sSysTmrObject.sysTickCount is initialized to zero (I think), and the _SYS_TMR_AlarmCallback() function is responsible for updating it every second.
 
So: Unless your program, somewhere, somehow, stores a meaningful value in sSysTmrObject.sysTickCount,
I think you will be reading the number of seconds that have elapsed since the system was initialized.
 
I'm implementing a UDP client application and I have a UDP time server on port 17 of my workstation. (Eventually this will be running along with a DHCP daemon and a specialized UDP server on a proprietary port on a dedicated laptop.)  The idea is that upon bootup, the PIC32 gets UNIX time (seconds elapsed since Jan 1, 1970) from the workstation and uses this as a base for time-of-day on the PIC32 system.  I haven't got there yet, but that's what I'm aiming for.
 

Well, I can tell you that, using Gregorian Calendar calculations, that is the number of seconds elapsed from Jan 1, 0000 through Jan 1 1970.  Of course that's nonsense since we didn't have January 1 in the year zero (Actually, there was no year zero---think about it!), and because calendar adjustments in the 16th though 18th centuries changed things considerably.  ("Lost" a bunch of seconds, among other things.)  But at least that's what comes out of the Gregorian calendar calculations if we project back from Jan 1 1970.
 
I can't imagine how or why the value 2208988800 is useful, but there it is.  I also can't imagine that this uncommented "magic number" is some cosmic coincidence.  (However: See Footnote)
 
I mean, someone had a reason to define that particular constant.  But, just because there is a reason doesn't mean it's a good reason.  I simply can't figure out whether it was a good reason.
 
 
Regards,

Dave
 
Footnote:

      以下为原文

   

 

好吧，我可以告诉你，使用公历计算，这是从1月1日到0000日到1月1日1970秒的时间。当然，这是胡说八道，因为我们没有在零年的1月1日（事实上，没有零年——想想吧！）因为在第十六到第十八个世纪的日历调整大大改变了事情。（“损失”了一大堆秒，等等）。但至少这是从格里高利日历计算出来的，如果我们从1月1日1970回来。我无法想象价值2208988800是如何或为什么有用的，但它确实存在。我也无法想象这个未被评论的“神奇数字”是某种宇宙巧合。（但是：请参阅脚注），它是用来从NTP时间转换为UNIX时间的值，即UNIX时间＝NTP秒- 2208988800（忽略NTP时间的小数部分）。



      以下为原文

   
Well, I can tell you that, using Gregorian Calendar calculations, that is the number of seconds elapsed from Jan 1, 0000 through Jan 1 1970.  Of course that's nonsense since we didn't have January 1 in the year zero (Actually, there was no year zero---think about it!), and because calendar adjustments in the 16th though 18th centuries changed things considerably.  ("Lost" a bunch of seconds, among other things.)  But at least that's what comes out of the Gregorian calendar calculations if we project back from Jan 1 1970.
 
I can't imagine how or why the value 2208988800 is useful, but there it is.  I also can't imagine that this uncommented "magic number" is some cosmic coincidence.  (However: See Footnote)
 

That is the value used to convert from NTP time to Unix time i.e. Unix time = NTP Seconds - 2208988800 (ignoring the fractional part of NTP time).
 
I think it is up to you to configure the System Timer in harmony.

在调用TCPIPPSNStppUutcSudisGET之前，必须确保SNTP服务器已成功联系，因此您必须调用TCTCPIPSNStpPyTimeStPGET，并且只有当返回值为SNTppRESixOK时，才能使用USECPPIN SNTPUTUC2SUDSGET.



      以下为原文

    Before calling TCPIP_SNTP_UTCSecondsGet you must be sure that a SNTP server has been contacted successfully, so you have to call TCPIP_SNTP_TimeStampGet and only when the return value is SNTP_RES_OK you can use TCPIP_SNTP_UTCSecondsGet.
 
Bye

我似乎记得1/1/1970是UNIX时间最初被构思并被使用的日期。



      以下为原文

   
 
I seem to remember that 1/1/1970 is the date when Unix time was originally conceived and has been used ever since.
 
just found this on stack overflow

首先，我要感谢你的回答和你对我的关注。我真的从你在帖子里所说的学到了很多东西。然后，我改变了我的代码中的一些东西，现在发生了如下的事情：第一次我调用函数，它把这个数字返回给我。33和40，然后，从第二次，它返回我正确的UNIX时间。目前，我可以接受这个折衷，我的代码似乎做我期待的，即使我想更好地理解这个话题。我会努力找出原因。如果我发现了一些新问题，我会再次问你。谢谢大家。



      以下为原文

    First of all, I would like to thank you for all your answers and the attention you gave me.
 
I really have learned many things from what you said in your posts.
 
Then, I changed a few things in my code and now the following happens: the first time I call the function, it returns me this number between 33 and 40; then, from the second time, it returns me correct Unix time.
 
At the moment, I can accept this compromise and my code seems doing what I am expecting even if I would like to understand better this topic. I will try to figure out why.
 
If I found some new problems, I would ask you again.
 
Thank you all. 

你的系统是如何获得时间的？它是否连接到SNTP服务器，如上所述？如果是这样，就好像第一个呼叫是在接收到响应之前发出的。



      以下为原文

   


How is your system obtaining a time at all?
Is it connecting to an SNTP server as mentioned above?
If so, it sounds like the first call is made before a response is received.
 

是的，我也在考虑这个问题。



      以下为原文

   


Yep, I was thinking about this as well.

必须连接到一个NTP服务器-这是唯一的时间可以设置。我似乎记得你可以检查的实时状态，即是否有一个NTP时间同步发生。



      以下为原文

   


must be connecting to an ntp server - that's the only way the time can be set.
I seem to remember you can check the status of the real time, i.e. whether an ntp time sync has happened.

是的，我使用SNTP来通过时间服务器（池.ntp.org）获取时间。问题是肯定的，第一个调用是在收到响应之前进行的。幸运的是，这不是我的代码中的一个关键问题，因为我可以丢弃从第一个调用派生的结果并开始存储数据。从给我当前UNIX时间的第二个调用中，我会有另一个关于我的项目的问题，但是我认为在这里请求它将是偏离主题，因为它不关心SNTP。谢谢你的帮助，洛伦佐。



      以下为原文

    Yes, I get my time through a time server (pool.ntp.org) using SNTP. 
 
The problem is definitely what you are saying, first call is made before a response is received. 
 
Luckily, this is not a crucial problem in my code because I can discard the results derived from the first call and start to store data from the second call which gives me current Unix time.
 
I would have another question about my project but I think that asking it here would be off topic because it does not concern SNTP.
 
In case, I will open another post. Thank you for your help,
 
Lorenzo. 

HII不认为丢弃固定数量的值是最好的方法。它总是有可能无法达到SNTP服务器。您应该一直测试SNTP服务器已经被接触，并且在进行常规操作之前正确地更新了时间。否则，如果SNTP Serv.ER是不可及的，你的应用程序将产生不可用的数据。只是我的2美分…最好的JoGeEPS：当处理通信总是“期望最好但准备好最坏”。



      以下为原文

    Hi
 
I don't think discarding a fixed number of values is the best approach.
Its always possible that an SNTP server can not be reached at all.
 
You should allways test that an SNTP server has been contacted and time was correctly updated before proceeding with regular operation.
Otherwise if an SNTP server is unreachable your application will produce unusable data.
 
Just my 2 cents...
 
Best regards
Jorge
 
PS: When dealing with communications always "expect the best but be ready for the worst".
 
 

这里是如何检查NTP时间同步是否已经收到：



      以下为原文

    and here is how to check if ntp time sync has been received:
 
  uint64_t sntpSeconds;
  TCPIP_SNTP_RESULT   sntpResult;
  sntpSeconds = TCPIP_SNTP_UTCSecondsGet();   
  sntpResult = TCPIP_SNTP_LastErrorGet();
 
  if (sntpResult == SNTP_RES_OK)
  {
       // use sntpSeconds as we have received a time sync
  }

这样做是错误的。你如何保证第二次调用总是正确的？



      以下为原文

   
 
That's exactly the wrong way to do it.
 
How do you propose to guarantee that the second call will always be correct?
 

我非常简单地检查我们有一年的时间设置为…2000（或者返回代码，YEP）。



      以下为原文

    I, much trivially usually just check that we have an year set to >2000 ...
 
(or the return code too, yep)

好了，SNTP！我知道，SNTP中的S代表什么（提示：不是“简单”）。它从一开始就是设计缺陷。你必须不时地给SNTP挠痒痒，以获得一个新的时间。但是，你也必须进行投票，直到它真的有了新的时间（有一个函数，忘记了名字）。它在启动后大约3次失败。我修补了和声的SNTP，所以它确实调用了回调函数，如果它真的有了新的时间。所以，你必须小心对待那个小家伙。我也忽略了低于140000000的次数（多少个零点？）如果你看代码，你会发现它没有任何关于ping时间的数学。太粗糙了！编写一个更好的芯片是很容易的。Microchip称之为“生产”，我称之为“……”，我自己写在我的列表上，不断走向列表的开头。Nick。



      以下为原文

    Well, the SNTP!
 
I do know, what the S in SNTP stands for (hint: not "simple").
It is a design flaw from the beginning. You have to tickle the SNTP every once in a while to fetch a new time. But then, you also have to poll until it actually DID get a new time (there is a function, forgot the name). Which fails here after about 3 time after having booted.
I patched Harmony's SNTP so it does call a callback-function if it actually did get a new time. So you have to care way less for that critter.
Also, I do ignore times that are below 140000000 (how many zeros?).
If you look at the code, you will see that it doesn't do any math regarding ping times. It is crude! And it would be quite easy to write a better one.
Microchip calls it "production", I call it ...
 
Writing my own is on my list and constantly moving toward the beginning of the list.
 
Nick

是的，这是从MLA移植的剩下的几个模块中的一个，我们还没有（重新）设计/重写的时间。回调函数是非常有用的，并且会立即添加。谢谢您的建议。-系统计时器仅用于保持NTP服务器的2次读取之间的时间差。因此，不需要用任何“日期/时间”值初始化系统计时器。-TeTCPIPSntpUutCudisGET（）返回当前时间，但只有获取了时间戳。不应该跳过调用tocPIPPnStppTimeTypPGET（）！否则，没有服务器时间。返回的值是错误的。AdTCPPIPSNTPTPyTimeStPGET（）告诉你。是的，一个改进是将UTC时间添加到TCPPIpSntpPyTimeStPGET（）中，并将旧的MLA函数TCPIpSntppUutcSudisGET（）全部删除。-“你必须不时地向SNTP发痒以获取新的时间”。不确定我知道你的意思，它在后台运行，不需要任何干预。请给出一些细节，以便我们可以修复行为，如果需要的话。



      以下为原文

   
 
Yes, this is one of the few modules remaining that has been ported from MLA, and we didn't have (yet) the time to redesign/rewrite.
 
- A callback function is something very useful and will be added immediately. Thank you for the suggestion.
 
- The system timer is used only for keeping the time difference between 2 reads of the NTP server. So, there is no need to initialize the system timer with any "date/time" value.
- The TCPIP_SNTP_UTCSecondsGet() returns the current time but only if a time stamp was acquired. The call to TCPIP_SNTP_TimeStampGet() should not be skipped! Otherwise, without server time. the returned value is wrong. And TCPIP_SNTP_TimeStampGet() tell you just that.
Yes, an improvement would be to  add the UTC time to TCPIP_SNTP_TimeStampGet() and get rid of the old MLA function TCPIP_SNTP_UTCSecondsGet() all together. 
- "You have to tickle the SNTP every once in a while to fetch a new time". Not sure I know what you mean, it runs in the background, without need for any intervention. Please give some details so we can fix the behavior, if needed.