61–70 of 150 posts
Earlier quoted context omitted.
Python 2.7.17 (default, Dec 31 2019, 23:59:25) Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import datetime >>> datetime.strptime('Sat 29 Feb 12:00:00 PM', '%a %d %b %I:%M:%S %p') Traceback (most recent call last): File " ", line 1, in ValueError: day is out of range for month
This is because 1900 is the default year in datetime. 1900 was not a leap year.
Stupid Q: Why doesn't the syslog protocol (RFC5424) deal with leap seconds (the seconds field goes to 00-59, not 00-60)? Are they using UTC (they would have to ignore LS and have crappier logs) or TAI (doesn't have LS)? https://mailarchive.ietf.org/arch/msg/syslog/DDLgKsRPITFXYSB... http://www.madore.org/~david/computers/unix-leap-seconds.htm... https://tools.ietf.org/html/rfc5424 https://cr.yp.to/libtai/tai64.html h…
Is there a real need for syslog to handle leap seconds? As that email you linked to points out, most implementations are likely to screw it up to some extent; requiring everyone to ignore leap seconds seems to narrow the range of possible behaviors. It also strikes me that syslog timestamps aren't something you should be depending on too heavily in the first place, especially not for things like calculating precise t…
Throwing shade without evidence doesn't demonstrate professionalism, it demonstrates laziness.
Correlation on high-volume production systems requires precise timestamps all the time.
Earlier quoted context omitted.
Almost all the edge cases with time have to do with localization. Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. Adjust above sentence to reflect the level of precision and range your use case needs. You are now done for 80% of use cases (perf timing, logging, timeouts, event storage, event ordering within jitter). If you need to parse/display for hum…
I've come to the same conclusion as you: Keep time as a purely monotonic integer for everything and convert that as needed to display to humans. This also pushes all the madness to the edges and out of the business logic. That being said, this works well for applications that are not "date intensive" so to speak. If your business logic has to deal specifically with calendar dates, e.g., monthly events, then you have…
Here's mine: https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/e0be9dcd8e96f9...
I respect wanting or needing to do this with just the builtin datetime module. For everyone else, I recommend relativedelta from the dateutil package: https://dateutil.readthedocs.io/en/stable/relativedelta.html e.g.: >>> from dateutil.relativedelta import relativedelta >>> date = datetime.utcnow().date() >>> date datetime.date(2020, 2, 29) >>> date + relativedelta(years=1) datetime.date(2021, 2, 28)
Thanks.
Stupid Q: Why doesn't the syslog protocol (RFC5424) deal with leap seconds (the seconds field goes to 00-59, not 00-60)? Are they using UTC (they would have to ignore LS and have crappier logs) or TAI (doesn't have LS)? https://mailarchive.ietf.org/arch/msg/syslog/DDLgKsRPITFXYSB... http://www.madore.org/~david/computers/unix-leap-seconds.htm... https://tools.ietf.org/html/rfc5424 https://cr.yp.to/libtai/tai64.html h…
Is there a real need for syslog to handle leap seconds? As that email you linked to points out, most implementations are likely to screw it up to some extent; requiring everyone to ignore leap seconds seems to narrow the range of possible behaviors. It also strikes me that syslog timestamps aren't something you should be depending on too heavily in the first place, especially not for things like calculating precise t…
Earlier quoted context omitted.
Actually, it's signed 32-bit integers that overflow in 2038. Signed integers have been used because people wanted to store dates earlier than 1970 too.
And probably because signed integers are a default choice in certain languages and/or maybe on certain architectures. Java, for example, famously doesn't even have an unsigned 32-bit integer primitive type. (But it has library functions you can use to treat signed integers as unsigned.) Ultimately not a good design choice, but the fact that it actually wasn't that limiting and relatively few people care or notice tel…
AFAIK, that doesn't exist? Otherwise, unsigned would also have UB?
This is why no one should ever ever write their own Time or Date library. The number of edge cases is simply enormous
Almost all the edge cases with time have to do with localization. Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. Adjust above sentence to reflect the level of precision and range your use case needs. You are now done for 80% of use cases (perf timing, logging, timeouts, event storage, event ordering within jitter). If you need to parse/display for hum…
> Confirmed! Your mystery Leap Year offer awaits inside. How much will you save?
The second arrived at 9:54 AM, with subject
> Oops! Your code is fixed. (We shoulda looked before we leap-yeared...)
The messages themselves appear to be identical except for some query parameters on some URLs, so I'm guessing that whatever they botched for leap year was on the server when one tried to respond to the offer.
Botching Feb 29 in general date handling code is embarrassing, but there is it least a somewhat plausible excuse that you just forgot about that special case. But botching Feb 29 in code that is meant to only work on Feb 29? Wow.
Earlier quoted context omitted.
Is there a real need for syslog to handle leap seconds? As that email you linked to points out, most implementations are likely to screw it up to some extent; requiring everyone to ignore leap seconds seems to narrow the range of possible behaviors. It also strikes me that syslog timestamps aren't something you should be depending on too heavily in the first place, especially not for things like calculating precise t…
it's bad enough guessing dmy or mdy, without wondering if we earned interest on that 10 billion euros that appears to have spent an entire second in a transit account earning 2.7% per annum (legal think 'annum' implicitly includes the leapsecond, an assurance resting on dozens of assumptions and misunderstandings of many ibscure treaties and standards and policies, modulo the case law in jurisdictions where precedent…
Earlier quoted context omitted.
Is there a real need for syslog to handle leap seconds? As that email you linked to points out, most implementations are likely to screw it up to some extent; requiring everyone to ignore leap seconds seems to narrow the range of possible behaviors. It also strikes me that syslog timestamps aren't something you should be depending on too heavily in the first place, especially not for things like calculating precise t…
Two wrongs don't make a right, but three lefts do. Throwing shade without evidence doesn't demonstrate professionalism, it demonstrates laziness. Correlation on high-volume production systems requires precise timestamps all the time.
Who's throwing shade?