|
yeah, Nathan, I was referring to RPG procedures on that time, I think the timestamp if I recall. But I also recently worked with IFS timestamps (epoch-1970) from RPG API calls and SQL Server timestamps set from Java timestamps (with 9 places provided for resolution of seconds) via RPG JNI, so it's all blurring together by now.The "lot of slack"-problem has been solved pre-SOAP in the ntp protocol[1], so you need to write a ntp-client and call that instead :)
I do recall it was from an RPG program timestamp function that I'm referring to where time is only populated to milliseconds, and definitely not the gettimeofday() API. I haven't used that yet.
But regarding the epoch-1970, I was working with the normal seconds since 1970 count stored in file timestamp. The gettimeofday() API must use the extended epoch count that joins in another integer for second precision count.
I don't have any idea how precisely that's set, but it'd be interesting if RPG time is set to only milliseconds but timeofday() integers set to greater precision than that, like microsecinds. I would think the source would be the same, an RTC chip or whatever. (oh wait, this is the age of the internet - a SOAP call to the National Time whatchmajiggy to get an atomic crystal controlled count, plus or minus a little slack for the SOAP call. ok, plus a lot of slack. :)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.