[flagged]
The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
61–70 of 106 posts
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#62Until 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.
You are perfectly wrong, the day is the main calendar object related to the epoch seconds.
I wrote conversion code, I know what I am talking about.
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#63Earlier quoted context omitted.
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.
Yeap, this is why I said it is kind of easy.
Until you know properly the leap years. Leap year rules on the long run are are bit funky. Just have a look at wikipedia.
(do not use gogol search since they are now forcing javascript by default)
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#64For 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 r…
And the answer is to use `gmtime()`, which AIX doesn't have and which Windows calls something else, but, whatever, if you need to support AIX you can use an open source library.
AIX has gmtime [0], too. Since at least 7.1.
[0] https://www.ibm.com/docs/en/aix/7.1?topic=c-ctime-localtime-...
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#6513 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++
#66Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#67Earlier quoted context omitted.
That is fine as long as the input / output is always in UTC... but at the end of the day you often want to communicate that timepoint to a human user (e.g. an appointment time, the time at which some event happened, etc.), which is when our stupid monkey brains expect the ascii string you are showing us to actually make sense in our specific locale (including all of the warts each of those particular timezones have,…
That's a localization task, not timekeeping task.
It is not, if what the user expects to stay constant is their local calendar/wall clock time rather than the UTC instant. Which is usually the case. This is a transformation that needs late binding as DST and timezone rules can change, so it can't just be handled as a localisation transformation on input/output
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#68The 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.
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#69Is 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.
Re: The surprising struggle to get a Unix Epoch time from a UTC string in C or C++
#70Earlier quoted context omitted.
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.
Debian’s vixie-cron had a bug [0] where if the system TZ was changed without restarting crond, it would continue to run jobs based on the old TZ. It checked for DST transitions, but not TZ.
In fairness, it’s not something that should happen much at all, if ever.
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019716