0

In a simple test getting the elapsed time in seconds since de Unix Epoch (01/01/1970 00:00:00 UTC) to 22 of February of 2019, it has returned a huge number of 18446744072104596016

Why not just 1550793600 seconds?

Isn't the time_t value portable?


The tm struct printed out in gdb console had the following values just before calling mktime():

(gdb) p ltm
$4 = {tm_sec = 0, tm_min = 0, tm_hour = 0, tm_mday = 22, tm_mon = 1, tm_year = 19, tm_wday = 0, tm_yday = 0, tm_isdst = 0}
5
  • How are you obtaining and printing the time_t value?
    – pmg
    Commented Feb 22, 2019 at 18:41
  • 3
    Post the actual code that shows mktime() returning such a huge value. Commented Feb 22, 2019 at 18:42
  • 6
    tm_year = 19 that's year 1919, it's returning a big negative number.
    – KamilCuk
    Commented Feb 22, 2019 at 18:50
  • @KamilCuk you nailed it! That answers everything! This year came outside from an argument, I didn't realize that it was outside of the desired range.
    – Luciano
    Commented Feb 22, 2019 at 18:58
  • @KamilCuk tm_year = 19 that's year 1919, it's returning a big negative number. Indeed. Took me a while to confirm that the Unix date for Feb 22, 1919 is actually 18446744072104596016 if a 64-bit time_t is viewed as an unsigned value. Commented Feb 22, 2019 at 19:06

2 Answers 2

4

Given

tm_year = 19

you are incorrectly using mktime() if you are expecting that input to represent the year 2019.

Per 7.27.1 Components of time, paragraph 4 of the C standard:

The tm structure shall contain at least the following members, in any order. The semantics of the members and their normal ranges are expressed in the comments.

     int    tm_sec;           //   seconds after the minute -- [0, 60]
     int    tm_min;           //   minutes after the hour -- [0, 59]
     int    tm_hour;          //   hours since midnight -- [0, 23]
     int    tm_mday;          //   day of the month -- [1, 31]
     int    tm_mon;           //   months since January -- [0, 11]
     int    tm_year;          //   years since 1900
     int    tm_wday;          //   days since Sunday -- [0, 6]
     int    tm_yday;          //   days since January 1 -- [0, 365]
     int    tm_isdst;         //   Daylight Saving Time flag

Note that the tm_year value is denoted in years since 1900.

You are likely getting the time_t value for Feb 22, 1919, which is -1604966400, or 18446744072104596016 unsigned.

1
  • I also have too much second but the reason is that high bytes are 0x49FB. why? tm tm; strptime(date, "%a, %d %b %Y %H:%M:%S", &tm); type_t respDate = mktime(&tm); // type_t is long long ESP_LOGI(TAG, "xxx %s, %d, 0x%llX, %lld", date, tm.tm_year, respDate >> 32, respDate & 0xFFFFFFFF); //I (15448) app: xxx Thu, 04 Nov 2021 15:52:34 GMT, 121, 0x49FB, 1636041154
    – ilya
    Commented Nov 4, 2021 at 15:54
1

In binary 18446744072104596016 is 1111111111111111111111111111111110100000010101100101001000110000 having 64 bits

probably are you using the negative value -1604955598 as an unsigned one

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.