starseeker (Jul 26 2023 at 14:35): starseeker (Jul 26 2023 at 14:35):@Sean I recall back in the day we incorporated y2038 into libbu in order to ensure we could handle 2038+ dates even in a 32 bit environment. Do we still need to do that, do you think? I'm wondering if using some of the newer C++ chrono/date functionality under the hood might be better - there doesn't seem to be much activity on the upstream of y2038 and it'd be nice to be able to base that part of libbu on something in a standard...
starseeker (Jul 26 2023 at 14:37):(full disclosure - the immediate pain point with y2038 is my Ubuntu machine's gcc for some reason complaining about mismatched LTO versions with the y2038 .o output when building libbu, but it made me also wonder if it's still necessary to even include y2038 at all... the LTO error isn't y2038's fault, it's more likely something strange about my machine's compiler setup.)
Erik (Jul 27 2023 at 21:34):glad my p75 running slackware will still be supported :D duck
Sean (Aug 06 2023 at 14:44):I guess it depends where all y2038 has its fingers. If it's isolated or already wrapped behind something, I don't see why it couldn't be converted to STL -- that almost certainly will be compliant. Just wouldn't want to convert a bunch of libbu files to c++ just for date/time purposes. Is it encapsulated? Otherwise, I'd leave it alone until it exhibits a cost more than a few minutes.
Sean (Aug 06 2023 at 14:46):That LTO issue sounds like a bigger deal, and y2038 is just the symptom provoking it.? Why would there be mismatched LTO versions on anything is the question to be answered first it seems to me.
starseeker (Aug 06 2023 at 16:53):I'm pretty sure the LTO thing is some sort of misconfiguration on my box - it was just the context that prompted me to wonder if we still need y2038.
starseeker (Aug 06 2023 at 16:56):IIRC y2038 is underneath bu_utctime - I don't think we've used it anywhere else.
starseeker (Aug 06 2023 at 16:58):Not a big deal either way, just thought it might be worth considering using something in a standard for code cleanup/simplification, if all the necessary pieces are in fact in the C++ standard.
Sean (Aug 06 2023 at 16:59):Yeah, then if it's underneath, it's totally fair game and easy to gut with a different implementation. I got no attachment to it.
starseeker (Aug 06 2023 at 17:01):IIRC the datetime libbu tests have a few cases intended to trigger the y2038 issue, so I think we're already set up to detect if a replacement solution has a problem. Frankly, bigger challenge at this point would probably be getting a 32 bit box set up for testing - I'd have to assemble a VM for the purpose.
starseeker (Aug 06 2023 at 17:02):Good project for a lazy Friday afternoon sometime (or maybe a student exercise)
Last updated: Jan 09 2025 at 00:46 UTC