I must add that I do appreciate you challenging the status quo. Excited to see where your library leads.
> modern datetime libraries … in other languages choose to not represent these 'missing' local times.
Another edge case with throwing errors over gap times is eventually a region’s dst policies may change. So what used to be valid can now be invalid (and vice versa). Updating the library must be done with an audit of existing data, or suffer loud unexpected failures.
Thanks for taking the time to address this critic. Easier to be a critic than a creator after all.
The author provides this example to illustrate inconsistent handling of non-existent datetimes:
# This time doesn't exist on this date
d = datetime(2023, 3, 26, 2, 30, tzinfo=paris)
# No timestamp exists, so it just makes one up
t = d.timestamp()
datetime.fromtimestamp(t) == d # False
Criticisms:
1) The example would fail just as well for any datetime with given tzinfo. Because fromtimestamp returns native datetimes.
2) The timestamp isn't just "made up". Its behaviour is clearly documented in PEP 495, as linked by the author [0]. In this case it consistently corresponds to datetime(2023, 3, 26, 3, 30, tzinfo=paris).
Finally if we disallow creating non-existent datetimes in the proposed library, how do we represent the 2am in "clock changes forwards at 2am"? Use 3am? There are tradeoffs.
While it’s true starting a blog can be difficult for those with little technical know-how, once you get past that, you’ll run into the challenge that is building up your following and brand.
Any successful bloggers want to chime in on how to overcome this?
Show clear steps with images on the download page that direct them to click "More Info" to run the app. Eventually the app builds up reputation (at least until the cert expires). How effective would this approach be?
Though this has been discussed many times, I must say the trend of using touchscreens to replace dials and buttons on cars is extremely worrying. It’s entirely an aesthetic and cost saving decision at the expense of safety and UX.
Their unique pricing structure is that listeners pay 0.002 for the 1st play of a song, 0.004 for the 2nd, and it keeps doubling until you reach the 9th play where you will have paid around a dollar to finally own it.
This is just my limited understanding of the rather inconsistent marketing copy. There is also a section about using a blockchain for DJs which I will not even try to comprehend on a weekend.
> modern datetime libraries … in other languages choose to not represent these 'missing' local times.
Another edge case with throwing errors over gap times is eventually a region’s dst policies may change. So what used to be valid can now be invalid (and vice versa). Updating the library must be done with an audit of existing data, or suffer loud unexpected failures.
Thanks for taking the time to address this critic. Easier to be a critic than a creator after all.