Live data from Hacker News

The surprising struggle to get a Unix Epoch time from a UTC string in C or C++

berthub.eu

41–50 of 106 posts

Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++

#41
post #27

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.

I don’t know. I’ve written that seemed like obvious simple code that got tripped up with the 25 hour day on DST transition. That’s when I learned to stick to UTC.

Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++

#43

Earlier quoted context omitted.

Was waiting for rustaceans to come and base c/cpp.. didn’t take long

They have five comments ever. What makes you think they use rust?

emcell is the name of a rust crate

Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++

#44

My 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?

Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++

#46

Is 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…

[deleted]

Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++

#47

Is 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…

"Mon, 20 Jan 2025 06:07:07 GMT"

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 anyway

Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++

#49
post #44

My 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?

I think the parent is describing a "bring your own library" approach where a set of known to the author algorithms will be used for those calculations and the only thing the host language will be used for is the parse/convert.

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++

#50
post #44

My 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?

Adding or subtracting "months" is inherently difficult because months don't have set lengths, varying from 28 through 31 days. Thus adding one month to May 31 is weird: should that be June 30 or July 1 or some other date?

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.

Post reply on HN