limitless_times - time handling functions to overcome some annoying limits It did bother me since a while that the common time functions in C are not only slow usually but that the common implementations don't even support any dates and times before 1970 because they are usually unable to handle negative time_t values. Even worse there exist that nightmare of the daylight saving rules all over the world and a thread save conversion between the the times of different time zones is a pretty hard thing to do. The math itself is not that hard of course as long as you know the time offsets and the daylight saving rules. If it comes to myself I did just want some fast, reliable and portable functions for my applications and especially for my network loggings in the several systems all over the world. The wrappers for gmtime_r, mkgmtime, mktime and localtime_r here are able to handle the Gregorian time even back to the age of dinosaur and the same time span ahead in the future too. Additionally there there are the functions mktime_of_zone() and localtime_of_zone() now which provide a thread save conversion between the UTC time of a time_t and the times in given time zones and are able to handle the daylight saving rules of the different zones. For speeding the calculations up a pre-calculated concersion data can be used that contains the required time-zone information. Thread safety may be a problem regarding the standard C functions mktime() and localtime_r() because those functions rely on the environment parameter TZ which can be required to change at runtime once the time zone is changes. The C standard says about the *_r time functions that they "shall not be subject to data races, unless the time or calendar state is changed in a multi-thread execution." That's why it's pretty dangerous to use those functions in big multi-threaded and portable software projects if any time zone adjustments or convertions at runtime need to be handled. For being thread safe you need just call update_time_zone_info() before creating any threads. In case that you need changes of TZ or your local time zone during at random times once your process is running you may provide an own mutex lock and unlock function for init_time_api_lock() and rely on the functions provided by this API. The support of the daylight saving rules is not that funny to implement but the functions new_mktime and new localtime_r here should handle them right as long as the environment variable TZ is set correctly. The default value is searched in /etc/localtime if that file exists as common in many Unix systems. The algorithm doesn't care the true binary format of the time zone data base files but extracts the TZ value at the end of that file only. This works in Linux and BSD but does not care about the big bunch of the historical time offsets and daylight saving rules. Of course I doubt that any of us will go back in time for enjoying those old days again and for this it shouldn't be a big problem for most developers. Be aware that the provided functions don't care about any leap seconds as well. Those are applied at random times for adjusting the timegap between the very local Gregorian time and the UTC time but a Gregorian year has an even bigger deviation from an average tropical year either and leap seconds can't fix the problems that the GPS and other systems face either. The Unix standard says that "As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds." ( https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15 ) For this leap seconds are usually ignored and I guess it's pretty OK to do so as well. A Gregorian year lasts currently a bit longer than a tropical year either and in a few ten thousend years after the earth rotation has slowed down a bit more the time will match again and for this it seems rather an academic problem of a nitpicker if somebody has a problem with that. For testing the functions and comparing the speed with the compiler build-in functions you may execute the test_times.c right as a shell script in a Linux or BSD system of your choice where a C compiler exist. There is a little test solution for Visual Studio as well now here. Why that 'Civil Usage Public License'? The license is kind of a little mix of the conditions of BSD or Apache license but in opposite to the former it prohibits any usage for weapons, spyware and systems for a secret monitoring of people without their knowledge and prior agreement. I dislike the idea to find anything of my software in military devices, weapons or spyware because it's traceably in the binaries of the most recently available compilers. The license is not a big deal for most people except for the ones who make money out of wars and things that are usually a nasty stuff. I don't expect anything good in return of supporting those people with this. But the license is much more permissive if it comes to a commercial usage than something like the GPL. It's for sure a good idea to use the software legally only and to care about the conditions of the license. Please be aware that this code is despite of the very permissive license no public domain software! ( Except the list of time zones that remains public domain as in the IANA time-zone database version 2024b https://www.iana.org/time-zones ) Life is great once there are less limits and problems and for this it's about time for limitless times now. Kind regards, Klaus Lux