mktime fails in an osmo-hlr test case with glibc 2.29 on ubuntu 19.04 with "Value too large for defined data type" [1]. The same test works fine on other linux distributions with earlier glibc versions. There is another downstream bug report with these symptoms for glibc 2.28 in the fedora bug tracker, and it has a reproducer in the description [2]. I was able to reproduce the problem with that test program, on ubuntu 19.04 with glibc 2.29. Just like it says in the fedora tracker, the bug happens with the timezone set to UTC, but not if it is set to CET. The same workaround helps with the osmo-hlr test case. So it seems that this is a regression in glibc. [1]: https://osmocom.org/issues/4026 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1653340#c0
Would you please provide a minimal reproducer (C source code with the required setenv/tzset/mktime calls)? Thanks. If you use TZ=CEST, then it's actually an alias for UTC. The Fedora reproducer is invalid.
I think the fedora reproducer is valid. I did not use TZ=CEST, but TZ=CET. As written above: > the bug happens with the timezone set to UTC, but not if it is set to CET.
But TZ=CET works, so where is the bug?
The bug is, that it does not work with TZ=UTC. Ubuntu 19.04, glibc 2.29: $ TZ=CET ./reproducer Mon Mar 12 00:01:00 2012 $ TZ=UTC ./reproducer Error: unable to make time using mktime: Value too large for defined data type Debian 9, glibc 2.24: $ TZ=CET ./reproducer Mon Mar 12 00:01:00 2012 $ TZ=UTC ./reproducer Mon Mar 12 01:01:00 2012
But that is not a valid use of mktime.
I could not find a source that says using mktime with UTC is not allowed. Would you mind explaining why that is the case? Furthermore, mktime seems to be the recommended way to convert "struct tm" to time_t. Do you have a recommendation of what to use instead?
(In reply to Oliver Smith from comment #6) > I could not find a source that says using mktime with UTC is not allowed. > Would you mind explaining why that is the case? tm_isdst == 1 for UTC is invalid input for mktime. It is unclear what you are trying to accomplish.
I realize now that you also had pointed that out in the other bug report, sorry for not reading it carefully enough. Now I see what is going on, and the problem was in our code. We were converting a date string with strptime() to "struct tm", and then with mktime() to time_t. But our "struct tm" was not initialized, and strptime() does not set tm_isdst, so tm_isdst had a random value. Closing. Thank you!
*** Bug 25039 has been marked as a duplicate of this bug. ***
(In reply to Florian Weimer from comment #7) > (In reply to Oliver Smith from comment #6) > > I could not find a source that says using mktime with UTC is not allowed. > > Would you mind explaining why that is the case? > > tm_isdst == 1 for UTC is invalid input for mktime. It is unclear what you > are trying to accomplish. The previous behavior of TZ=UTC mktime was like timegm. It is still is, except when tm_isdst = 1. The man page does not reflect this fact strongly. Also EOVERFLOW is quite missleading, maybe EINVAL would be better?