81–90 of 106 posts
13 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.
[0] https://en.wikipedia.org/wiki/Year_2038_problem#Implemented_...
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...
Also, naming things, cache coherency, and off by one errors are the two hardest problems in computer science.
13 more years to go until the 2038 problem. Surely we'll have everything patched up by then..
The overflow happens at 2038-01-19T03:14:08Z.
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…
> 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.
But only when you don't want them to, when you do want them to do it it's still a pain.
Earlier quoted context omitted.
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.
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.
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.
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 r…
>>> from email.utils import parsedate_tz, mktime_tz
>>> mktime_tz(parsedate_tz("Fri, 17 Jan 2025 06:07:07"))
1737094027
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?
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…
> 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.