I think that time handling is the most hard thing in the world of programming. Explanation: you can learn heap sort or FFT or whatever algorithm there is and implement it. But writing your own calendar from scratch, that will do for example chron job on 3 am in the day of DST transition, that works in every TZ, is a work for many people and many months if not years...
Time handling is exceptionally easy. Time zone handling is hard. It doesn't help that the timezone database isn't actually designed to make this any easier.
The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
41–50 of 106 posts
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#42Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#43Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#44My personal rule for time processing: use the language-provided libraries for ONLY 2 operations: converting back and forth between a formatted time string with a time zone, and a Unix epoch timestamp. Perform all other time processing in your own code based on those 2 operations, and whenever you start with a new language or framework, just learn those 2. I've wasted so many dreary hours trying to figure out crappy t…
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#45Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#46Is it a struggle though? They needed to have a locale matching the language of the localised time string they wanted to parse, they needed to use strptime to parse the string, they needed to use timegm() to convert the result to seconds when seen as UTC. The man pages pretty much describe these things. The interface or these things could certainly be nicer, but most of the things they bring up as issues aren't even r…
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#47Is it a struggle though? They needed to have a locale matching the language of the localised time string they wanted to parse, they needed to use strptime to parse the string, they needed to use timegm() to convert the result to seconds when seen as UTC. The man pages pretty much describe these things. The interface or these things could certainly be nicer, but most of the things they bring up as issues aren't even r…
It is not. int main(void) { struct tm tm = {0}; const char *time_str = "Mon, 20 Jan 2025 06:07:07 GMT"; const char *fmt = "%a, %d %b %Y %H:%M:%S GMT"; // Parse the time string if (strptime(time_str, fmt, &tm) == NULL) { fprintf(stderr, "Error parsing time\n"); return 1; } // Convert to Unix timestamp (UTC) time_t timestamp = timegm(&tm); if (timestamp == -1) { fprintf(stderr, "Error converting to timestamp\n"); retur…
I thought the default output of date(1), with TZ unset, is something like
Mon Jan 20 06:07:07 UTC 2025
That's the busybox default anywayRe: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#48Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#49My personal rule for time processing: use the language-provided libraries for ONLY 2 operations: converting back and forth between a formatted time string with a time zone, and a Unix epoch timestamp. Perform all other time processing in your own code based on those 2 operations, and whenever you start with a new language or framework, just learn those 2. I've wasted so many dreary hours trying to figure out crappy t…
Starting from timestamp A, how do I find the Unix timestamp B corresponding to exactly 6 months in the future from timestamp B?
It does remove a lot of the ambiguity of "I wonder what this stdlib's quirks are in their date calculations" but it also seems like a non-trivial amount of effort to port every time.
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#50My personal rule for time processing: use the language-provided libraries for ONLY 2 operations: converting back and forth between a formatted time string with a time zone, and a Unix epoch timestamp. Perform all other time processing in your own code based on those 2 operations, and whenever you start with a new language or framework, just learn those 2. I've wasted so many dreary hours trying to figure out crappy t…
Starting from timestamp A, how do I find the Unix timestamp B corresponding to exactly 6 months in the future from timestamp B?
Try not to have to do this sort of thing. You might have to though, and then you'll have to figure out what adding months means for your app.