localtime() is off by about 460,000 years on RTL8710
I'm using an RTL8710 (running rustl8710, but that's irrelevant as far as this question goes, since all code I'm talking about is C code). The RTL8710 has proprietary libraries for some parts of the system, including localtime.
However, localtime seems to be off by about 460,000 years when using it like this (taken from the included NTP implementation):
long current_sec = 1543067026;
struct tm current_tm = *(localtime(¤t_sec));
This returns the following struct:
{tm_sec = 51,
tm_min = 36,
tm_hour = 15,
tm_mday = 25,
tm_mon = 8,
tm_year = -458682,
tm_wday = 2,
tm_yday = 267,
tm_isdst = -1515870811}
Obviously that's incorrect, it should be something close to 24 Nov 2018 13:52:04 GMT. It's not random though, because the time always seems to differ by around 2 hours and some minutes.
The only other noteworthy thing here is that the code uses the default system headers time.h and string.h (which would be from Ubuntu 18.10, 64bit in my case).
I have no idea what stdlib library RealTek is really using, but judging by debugging info (newlib/libc/time/lcltime.c), I'd guess that it's a (modified?) version of newlib.
c embedded localtime
edited Nov 24 '18 at 16:50
Clifford
59.4k859126
asked Nov 24 '18 at 14:11
Size43Size43
179112
add a comment |
I'm using an RTL8710 (running rustl8710, but that's irrelevant as far as this question goes, since all code I'm talking about is C code). The RTL8710 has proprietary libraries for some parts of the system, including localtime.
However, localtime seems to be off by about 460,000 years when using it like this (taken from the included NTP implementation):
long current_sec = 1543067026;
struct tm current_tm = *(localtime(¤t_sec));
This returns the following struct:
{tm_sec = 51,
tm_min = 36,
tm_hour = 15,
tm_mday = 25,
tm_mon = 8,
tm_year = -458682,
tm_wday = 2,
tm_yday = 267,
tm_isdst = -1515870811}
Obviously that's incorrect, it should be something close to 24 Nov 2018 13:52:04 GMT. It's not random though, because the time always seems to differ by around 2 hours and some minutes.
The only other noteworthy thing here is that the code uses the default system headers time.h and string.h (which would be from Ubuntu 18.10, 64bit in my case).
I have no idea what stdlib library RealTek is really using, but judging by debugging info (newlib/libc/time/lcltime.c), I'd guess that it's a (modified?) version of newlib.
c embedded localtime
edited Nov 24 '18 at 16:50
Clifford
59.4k859126
asked Nov 24 '18 at 14:11
Size43Size43
179112
So is it off by 460K years or by 2 hours?
– stackptr
Nov 24 '18 at 14:22
localtime(const time_t *timer)expects atime_t *, not necessarily along *. Usetime_t current_sec. If that is not close to a solution, you need to post a Minimal, Complete, and Verifiable example.
– chux
Nov 24 '18 at 14:50
@stackptr full date is off by 460K years, but time is correct within give or take two hours.
– Size43
Nov 24 '18 at 15:01
1
This code is literally pulled from the SDK provided by Realtek, so I'd expect it to work, but I'll make the suggested modifications and report back with the results. The minimal example is just adding a few headers and wrapping it in amain {}, I'll edit that into the question.
– Size43
Nov 24 '18 at 15:06
Check also endianness.
– linuxfan
Nov 24 '18 at 17:35
add a comment |
I'm using an RTL8710 (running rustl8710, but that's irrelevant as far as this question goes, since all code I'm talking about is C code). The RTL8710 has proprietary libraries for some parts of the system, including localtime.
However, localtime seems to be off by about 460,000 years when using it like this (taken from the included NTP implementation):
long current_sec = 1543067026;
struct tm current_tm = *(localtime(¤t_sec));
This returns the following struct:
{tm_sec = 51,
tm_min = 36,
tm_hour = 15,
tm_mday = 25,
tm_mon = 8,
tm_year = -458682,
tm_wday = 2,
tm_yday = 267,
tm_isdst = -1515870811}
Obviously that's incorrect, it should be something close to 24 Nov 2018 13:52:04 GMT. It's not random though, because the time always seems to differ by around 2 hours and some minutes.
The only other noteworthy thing here is that the code uses the default system headers time.h and string.h (which would be from Ubuntu 18.10, 64bit in my case).
I have no idea what stdlib library RealTek is really using, but judging by debugging info (newlib/libc/time/lcltime.c), I'd guess that it's a (modified?) version of newlib.
c embedded localtime
edited Nov 24 '18 at 16:50
Clifford
59.4k859126
asked Nov 24 '18 at 14:11
Size43Size43
179112
I'm using an RTL8710 (running rustl8710, but that's irrelevant as far as this question goes, since all code I'm talking about is C code). The RTL8710 has proprietary libraries for some parts of the system, including localtime.
However, localtime seems to be off by about 460,000 years when using it like this (taken from the included NTP implementation):
long current_sec = 1543067026;
struct tm current_tm = *(localtime(¤t_sec));
This returns the following struct:
{tm_sec = 51,
tm_min = 36,
tm_hour = 15,
tm_mday = 25,
tm_mon = 8,
tm_year = -458682,
tm_wday = 2,
tm_yday = 267,
tm_isdst = -1515870811}
Obviously that's incorrect, it should be something close to 24 Nov 2018 13:52:04 GMT. It's not random though, because the time always seems to differ by around 2 hours and some minutes.
The only other noteworthy thing here is that the code uses the default system headers time.h and string.h (which would be from Ubuntu 18.10, 64bit in my case).
I have no idea what stdlib library RealTek is really using, but judging by debugging info (newlib/libc/time/lcltime.c), I'd guess that it's a (modified?) version of newlib.
c embedded localtime
c embedded localtime
edited Nov 24 '18 at 16:50
Clifford
59.4k859126
asked Nov 24 '18 at 14:11
Size43Size43
179112
edited Nov 24 '18 at 16:50
Clifford
59.4k859126
asked Nov 24 '18 at 14:11
Size43Size43
179112
edited Nov 24 '18 at 16:50
Clifford
59.4k859126
edited Nov 24 '18 at 16:50
Clifford
59.4k859126
edited Nov 24 '18 at 16:50
Clifford
59.4k859126
59.4k859126
asked Nov 24 '18 at 14:11
Size43Size43
179112
asked Nov 24 '18 at 14:11
Size43Size43
179112
asked Nov 24 '18 at 14:11
Size43Size43
179112
179112
So is it off by 460K years or by 2 hours?
– stackptr
Nov 24 '18 at 14:22
localtime(const time_t *timer)expects atime_t *, not necessarily along *. Usetime_t current_sec. If that is not close to a solution, you need to post a Minimal, Complete, and Verifiable example.
– chux
Nov 24 '18 at 14:50
@stackptr full date is off by 460K years, but time is correct within give or take two hours.
– Size43
Nov 24 '18 at 15:01
1
This code is literally pulled from the SDK provided by Realtek, so I'd expect it to work, but I'll make the suggested modifications and report back with the results. The minimal example is just adding a few headers and wrapping it in amain {}, I'll edit that into the question.
– Size43
Nov 24 '18 at 15:06
Check also endianness.
– linuxfan
Nov 24 '18 at 17:35
add a comment |
So is it off by 460K years or by 2 hours?
– stackptr
Nov 24 '18 at 14:22
localtime(const time_t *timer)expects atime_t *, not necessarily along *. Usetime_t current_sec. If that is not close to a solution, you need to post a Minimal, Complete, and Verifiable example.
– chux
Nov 24 '18 at 14:50
@stackptr full date is off by 460K years, but time is correct within give or take two hours.
– Size43
Nov 24 '18 at 15:01
1
This code is literally pulled from the SDK provided by Realtek, so I'd expect it to work, but I'll make the suggested modifications and report back with the results. The minimal example is just adding a few headers and wrapping it in amain {}, I'll edit that into the question.
– Size43
Nov 24 '18 at 15:06
Check also endianness.
– linuxfan
Nov 24 '18 at 17:35
So is it off by 460K years or by 2 hours?
– stackptr
Nov 24 '18 at 14:22
So is it off by 460K years or by 2 hours?
– stackptr
Nov 24 '18 at 14:22
localtime(const time_t *timer) expects a time_t *, not necessarily a long *. Use time_t current_sec. If that is not close to a solution, you need to post a Minimal, Complete, and Verifiable example.– chux
Nov 24 '18 at 14:50
localtime(const time_t *timer) expects a time_t *, not necessarily a long *. Use time_t current_sec. If that is not close to a solution, you need to post a Minimal, Complete, and Verifiable example.– chux
Nov 24 '18 at 14:50
@stackptr full date is off by 460K years, but time is correct within give or take two hours.
– Size43
Nov 24 '18 at 15:01
@stackptr full date is off by 460K years, but time is correct within give or take two hours.
– Size43
Nov 24 '18 at 15:01
1
1
This code is literally pulled from the SDK provided by Realtek, so I'd expect it to work, but I'll make the suggested modifications and report back with the results. The minimal example is just adding a few headers and wrapping it in a
main {}, I'll edit that into the question.– Size43
Nov 24 '18 at 15:06
This code is literally pulled from the SDK provided by Realtek, so I'd expect it to work, but I'll make the suggested modifications and report back with the results. The minimal example is just adding a few headers and wrapping it in a
main {}, I'll edit that into the question.– Size43
Nov 24 '18 at 15:06
Check also endianness.
– linuxfan
Nov 24 '18 at 17:35
Check also endianness.
– linuxfan
Nov 24 '18 at 17:35
add a comment |
1 Answer
1
active
oldest
votes
Code is using the wrong type which leads to undefined behavior.1
// long current_sec = 1543067026;
time_t current_sec = 1543067026;
struct tm current_tm = *(localtime(¤t_sec));
Better code would test the localtime() return value before de-referencing it.
struct tm *p = localtime(¤t_sec);
if (p) {
struct tm current_tm = *p;
...
1 The wrong type width is evidenced by following.
int main() {
long current_sec = 1543067026;
struct tm current_tm = { .tm_sec = 51, .tm_min = 36, .tm_hour = 15, //
.tm_mday = 25, .tm_mon = 8, .tm_year = -458682, //
.tm_wday = 2, .tm_yday = 267, .tm_isdst = -1515870811 };
time_t t = mktime(¤t_tm);
printf("%16lxn%16llxn", current_sec, (unsigned long long) t);
}
Output
5bf95592
fffff2d55bf9a9f3
^^^^
Many bits lines up. I suspect the upper bit difference was due to junk bits being referenced by local_time() and lower bit difference due to extreme calculation, OP non-synchronized posting of code and purported output, or a difference between my and OP's standard library. Although time_t is zone-less, my and OP's timezone difference contributes to locatime()/mktime() differences.
answered Nov 24 '18 at 15:09
chuxchux
83.4k872152
Yup, this is it. The SDK implementation is just broken. Thanks! (for anyone else that ran into the same issue: you need to changelong update_sec, ...incomponent/common/network/sntp/sntp.ctotime_t update_sec, .... Same for both 3.5a and 4.0b of the SDK)
– Size43
Nov 24 '18 at 18:11
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53459016%2flocaltime-is-off-by-about-460-000-years-on-rtl8710%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Code is using the wrong type which leads to undefined behavior.1
// long current_sec = 1543067026;
time_t current_sec = 1543067026;
struct tm current_tm = *(localtime(¤t_sec));
Better code would test the localtime() return value before de-referencing it.
struct tm *p = localtime(¤t_sec);
if (p) {
struct tm current_tm = *p;
...
1 The wrong type width is evidenced by following.
int main() {
long current_sec = 1543067026;
struct tm current_tm = { .tm_sec = 51, .tm_min = 36, .tm_hour = 15, //
.tm_mday = 25, .tm_mon = 8, .tm_year = -458682, //
.tm_wday = 2, .tm_yday = 267, .tm_isdst = -1515870811 };
time_t t = mktime(¤t_tm);
printf("%16lxn%16llxn", current_sec, (unsigned long long) t);
}
Output
5bf95592
fffff2d55bf9a9f3
^^^^
Many bits lines up. I suspect the upper bit difference was due to junk bits being referenced by local_time() and lower bit difference due to extreme calculation, OP non-synchronized posting of code and purported output, or a difference between my and OP's standard library. Although time_t is zone-less, my and OP's timezone difference contributes to locatime()/mktime() differences.
answered Nov 24 '18 at 15:09
chuxchux
83.4k872152
Yup, this is it. The SDK implementation is just broken. Thanks! (for anyone else that ran into the same issue: you need to changelong update_sec, ...incomponent/common/network/sntp/sntp.ctotime_t update_sec, .... Same for both 3.5a and 4.0b of the SDK)
– Size43
Nov 24 '18 at 18:11
add a comment |
Code is using the wrong type which leads to undefined behavior.1
// long current_sec = 1543067026;
time_t current_sec = 1543067026;
struct tm current_tm = *(localtime(¤t_sec));
Better code would test the localtime() return value before de-referencing it.
struct tm *p = localtime(¤t_sec);
if (p) {
struct tm current_tm = *p;
...
1 The wrong type width is evidenced by following.
int main() {
long current_sec = 1543067026;
struct tm current_tm = { .tm_sec = 51, .tm_min = 36, .tm_hour = 15, //
.tm_mday = 25, .tm_mon = 8, .tm_year = -458682, //
.tm_wday = 2, .tm_yday = 267, .tm_isdst = -1515870811 };
time_t t = mktime(¤t_tm);
printf("%16lxn%16llxn", current_sec, (unsigned long long) t);
}
Output
5bf95592
fffff2d55bf9a9f3
^^^^
Many bits lines up. I suspect the upper bit difference was due to junk bits being referenced by local_time() and lower bit difference due to extreme calculation, OP non-synchronized posting of code and purported output, or a difference between my and OP's standard library. Although time_t is zone-less, my and OP's timezone difference contributes to locatime()/mktime() differences.
answered Nov 24 '18 at 15:09
chuxchux
83.4k872152
Yup, this is it. The SDK implementation is just broken. Thanks! (for anyone else that ran into the same issue: you need to changelong update_sec, ...incomponent/common/network/sntp/sntp.ctotime_t update_sec, .... Same for both 3.5a and 4.0b of the SDK)
– Size43
Nov 24 '18 at 18:11
add a comment |
Code is using the wrong type which leads to undefined behavior.1
// long current_sec = 1543067026;
time_t current_sec = 1543067026;
struct tm current_tm = *(localtime(¤t_sec));
Better code would test the localtime() return value before de-referencing it.
struct tm *p = localtime(¤t_sec);
if (p) {
struct tm current_tm = *p;
...
1 The wrong type width is evidenced by following.
int main() {
long current_sec = 1543067026;
struct tm current_tm = { .tm_sec = 51, .tm_min = 36, .tm_hour = 15, //
.tm_mday = 25, .tm_mon = 8, .tm_year = -458682, //
.tm_wday = 2, .tm_yday = 267, .tm_isdst = -1515870811 };
time_t t = mktime(¤t_tm);
printf("%16lxn%16llxn", current_sec, (unsigned long long) t);
}
Output
5bf95592
fffff2d55bf9a9f3
^^^^
Many bits lines up. I suspect the upper bit difference was due to junk bits being referenced by local_time() and lower bit difference due to extreme calculation, OP non-synchronized posting of code and purported output, or a difference between my and OP's standard library. Although time_t is zone-less, my and OP's timezone difference contributes to locatime()/mktime() differences.
answered Nov 24 '18 at 15:09
chuxchux
83.4k872152
Code is using the wrong type which leads to undefined behavior.1
// long current_sec = 1543067026;
time_t current_sec = 1543067026;
struct tm current_tm = *(localtime(¤t_sec));
Better code would test the localtime() return value before de-referencing it.
struct tm *p = localtime(¤t_sec);
if (p) {
struct tm current_tm = *p;
...
1 The wrong type width is evidenced by following.
int main() {
long current_sec = 1543067026;
struct tm current_tm = { .tm_sec = 51, .tm_min = 36, .tm_hour = 15, //
.tm_mday = 25, .tm_mon = 8, .tm_year = -458682, //
.tm_wday = 2, .tm_yday = 267, .tm_isdst = -1515870811 };
time_t t = mktime(¤t_tm);
printf("%16lxn%16llxn", current_sec, (unsigned long long) t);
}
Output
5bf95592
fffff2d55bf9a9f3
^^^^
Many bits lines up. I suspect the upper bit difference was due to junk bits being referenced by local_time() and lower bit difference due to extreme calculation, OP non-synchronized posting of code and purported output, or a difference between my and OP's standard library. Although time_t is zone-less, my and OP's timezone difference contributes to locatime()/mktime() differences.
answered Nov 24 '18 at 15:09
chuxchux
83.4k872152
edited Nov 24 '18 at 15:21
answered Nov 24 '18 at 15:09
chuxchux
83.4k872152
answered Nov 24 '18 at 15:09
chuxchux
83.4k872152
answered Nov 24 '18 at 15:09
chuxchux
83.4k872152
83.4k872152
Yup, this is it. The SDK implementation is just broken. Thanks! (for anyone else that ran into the same issue: you need to changelong update_sec, ...incomponent/common/network/sntp/sntp.ctotime_t update_sec, .... Same for both 3.5a and 4.0b of the SDK)
– Size43
Nov 24 '18 at 18:11
add a comment |
Yup, this is it. The SDK implementation is just broken. Thanks! (for anyone else that ran into the same issue: you need to changelong update_sec, ...incomponent/common/network/sntp/sntp.ctotime_t update_sec, .... Same for both 3.5a and 4.0b of the SDK)
– Size43
Nov 24 '18 at 18:11
Yup, this is it. The SDK implementation is just broken. Thanks! (for anyone else that ran into the same issue: you need to change
long update_sec, ... in component/common/network/sntp/sntp.c to time_t update_sec, .... Same for both 3.5a and 4.0b of the SDK)– Size43
Nov 24 '18 at 18:11
Yup, this is it. The SDK implementation is just broken. Thanks! (for anyone else that ran into the same issue: you need to change
long update_sec, ... in component/common/network/sntp/sntp.c to time_t update_sec, .... Same for both 3.5a and 4.0b of the SDK)– Size43
Nov 24 '18 at 18:11
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53459016%2flocaltime-is-off-by-about-460-000-years-on-rtl8710%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
So is it off by 460K years or by 2 hours?
– stackptr
Nov 24 '18 at 14:22
localtime(const time_t *timer)expects atime_t *, not necessarily along *. Usetime_t current_sec. If that is not close to a solution, you need to post a Minimal, Complete, and Verifiable example.– chux
Nov 24 '18 at 14:50
@stackptr full date is off by 460K years, but time is correct within give or take two hours.
– Size43
Nov 24 '18 at 15:01
1
This code is literally pulled from the SDK provided by Realtek, so I'd expect it to work, but I'll make the suggested modifications and report back with the results. The minimal example is just adding a few headers and wrapping it in a
main {}, I'll edit that into the question.– Size43
Nov 24 '18 at 15:06
Check also endianness.
– linuxfan
Nov 24 '18 at 17:35