from Hacker News

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

by PascalW on 1/19/25, 4:10 PM with 96 comments

• by chikere232 on 1/19/25, 7:18 PM

  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 relevant for the task they're trying to do. Why do they talk about daylight savings time being confusing when they're only trying to deal with UTC which doesn't have it?

• by d_burfoot on 1/19/25, 8:38 PM

  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!

• by 1970-01-01 on 1/19/25, 7:05 PM

  13 more years to go until the 2038 problem.

  Surely we'll have everything patched up by then..

• by account42 on 1/20/25, 2:35 PM

  The concept of a process-wide locale was a mistake. All locale-dependent functons should be explicit. Yes that means some programs won't respect your locale because the author didn't care to add support but at least they won't break in unexpected ways because some functions magically work differently between the user's and developers system.

• by jonstewart on 1/19/25, 8:39 PM

  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.

• by zX41ZdbW on 1/19/25, 7:18 PM

  The first rule of thumb is to never use functions from glibc (gmtime, localtime, mktime, etc) because half of them are non-thread-safe, and another half use a global mutex, and they are unreasonably slow. The second rule of thumb is to never use functions from C++, because iostreams are slow, and a stringstream can lead to a silent data loss if an exception is thrown during memory allocation.

  ClickHouse has the "parseDateTimeBestEffort" function: https://clickhouse.com/docs/en/sql-reference/functions/type-... and here is its source code: https://github.com/ClickHouse/ClickHouse/blob/74d8551dadf735...

• by p0w3n3d on 1/19/25, 8:46 PM

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

• by blindriver on 1/20/25, 3:59 AM

  I used the ICU packages when I needed to do something like this but it's been a decade since I coded in C++.

  https://unicode-org.github.io/icu/userguide/datetime/

• by havermeyer on 1/20/25, 4:39 AM

  The Abseil time library makes time and date parsing and manipulation a lot nicer in C++: https://abseil.io/docs/cpp/guides/time

• by rstuart4133 on 1/19/25, 9:34 PM

  For those skimmimg the problem is mktime() returns local time, and they want it in UTC. So you need to subtract the timezone used, but the timezone varies by date you feed mktime() and there is no easy way to determime it.

  If you are happy for the time to perhaps be wrong around the hours timezone changes, this is an easy hack:

      import time
      def time_mktime_utc(_tuple):
          result = time.mktime(_tuple[:-1] + (0,))
          return result * 2 - time.mktime(time.gmtime(result))
  

  If you are just using it for display this is usually fine as time zone changes are usually timed to happen when nobody is looking.

• by TZubiri on 1/20/25, 2:53 PM

  Fun fact, http 1 used to pass expirations and dates in string format.

  [Missing scene]

  " We are releasing Http1.1 specifications whereby expirations are passed as seconds to expire instead of dates as strings."

• by richrichie on 1/19/25, 10:13 PM

  > give us some truly excellent code that we really don’t deserve

  Why such self flagellation?

• by TZubiri on 1/20/25, 3:03 PM

  This comment section is so nerdy I love it.

• by udidnmem on 1/19/25, 5:56 PM

  You cannot since it's missing time zone

• by sylware on 1/19/25, 6:13 PM

  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 syscall output). Then, don't be scared, with a bit of motivation, you'll figure it out.