Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

berthub.eu

Post reply on HN
Print view View original

21–30 of 106 posts

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

#21

Post by Kwpolska »

DamonHD wrote: post #18
sylware wrote: post #4

Until you understand that the core of unix time is the "day", in the end, you only need to know the first leap year (If I recall properly it is 1972), then you have to handle the "rules" of leap years, and you will be ok (wikipedia I think, don't use google anymore since they now force javascript upon new web engines). I did write such code in RISC-V assembly (for a custom command line on linux to output the statx sy…

The core of the UNIX time is seconds since epoch, nothing else. 'Day' has no special place at all. There are calendars for converting to and from dates, including Western-style, but the days in those calendars vary in length because of daylight saving switches and leap seconds for example.

UNIX time ignores leap seconds, so every day is exactly 86400 seconds, and every year is either 365*86400 or 366*86400 seconds. This makes converting from yyyy-mm-dd to UNIX time quite easy, as you can just do `365*86400*(yyyy-1970) + leap_years*86400` to get to yyyy-01-01.

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

#22

Post by paxcoder »

johnisgood wrote: post #16
chikere232 wrote: post #12

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…

I can't find `timegm` neither in the C99 standard draft nor in POSIX.1-2024.

The first sentence of your link reads:

>The C/Unix time- and date-handling API is a confusing jungle full of the corpses of failed experiments and various other traps for the unwary, many of them resulting from design decisions that may have been defensible when the originals were written but appear at best puzzling today.

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

#24

Post by d_burfoot »

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 time processing APIs and libraries. Never again!

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

#27

Post by p0w3n3d »

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

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

#28

Post by timewizard »

p0w3n3d wrote: 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.

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

#29

Post by p0w3n3d »

timewizard wrote: post #28
p0w3n3d wrote: 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.

Meanwhile I edited my comment but we're still agreeing. And adding them for example to embedded systems is additional pain. Example: tram or train electronic boards / screens

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

#30

Post by jeffbee »

jonstewart wrote: post #25

The headline doesn’t match the article. As it points out, C++20 has a very nice, and portable, time library. I quibble with the article here, though: in 2025, C++20 is widely available.

Indeed. The article should be retitled "C still useless in 2025, including time handling".
Post reply on HN