[dead]
The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
71–80 of 106 posts
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#72Fun 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."
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#73Is 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…
> Is it a struggle though? It’s twelve lines or more, if you include the imports and error handling. Spreadsheets and SQL will coerce a string to a date without even being asked to. You might want something more structured than that, but you should be able to do it in far less than 12 lines. C has many clunky elements like this, which makes working with it like pulling teeth.
almost like C is logically operating at a lower level than spreadsheets or SQL or something
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#74Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#75Is 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…
> Is it a struggle though? It’s twelve lines or more, if you include the imports and error handling. Spreadsheets and SQL will coerce a string to a date without even being asked to. You might want something more structured than that, but you should be able to do it in far less than 12 lines. C has many clunky elements like this, which makes working with it like pulling teeth.
> you should be able to do it in far less than 12 lines
In C++, maybe. In C, not necessarily. If you're not willing to reinvent the wheel why'd you choose C anyway?
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#76Earlier quoted context omitted.
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.
Welcome to Business Logic. This is where I'd really like pushback to result in things that aren't edgecases. However you also run into day to day business issues like: * What if it's now a Holiday and things are closed? * What if it's some commonly busy time like winter break? (Not quite a single holiday) * What if a disaster of somekind (even just a burst waterpipe) halts operations in an unplanned way? Usually flex…
Do all edge cases need to be handled? Just be late when there's a holiday.
72 business hours sounds more like human time than computer time anyways.
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#7713 more years to go until the 2038 problem. Surely we'll have everything patched up by then..
It worries me how blasé we seem to be to the 2038 problem. I wonder if people will still be repeating the "Y2k myth" myth as things start to fail.
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#78This comment section is so nerdy I love it.
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#79My 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?
The difficulty of this problem rests on the ambiguity of the phrase "exactly 6 months", which is going to depend totally on the precise business logic. But there's no reason to suppose that the requirements of the business logic will agree with the concepts implemented by the datetime library.
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#80The 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.
Totally agree. Python's gettext() API feels so ancient because it can only cope with one locale at a time, and it would love to get that locale from an environment variable. Not ideal for writing an HTTP service that sends text based on the Accept-Language header.