guitarnick

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).

[0] https://peps.python.org/pep-0495/

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?

Can this be worked around with UX?

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.

Another advantage of developing close to plain HTML is that you’re free from the js next-shiny-thing hamster wheel.

For example, I had thought Gatsby was the hip way to create static sites in 2019. Then another comment here mentioned it’s Next.js now.

We were just about to submit a ticket when the forecast/breakdown returned to normal. Looks like fixes are rolling out.

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.

In half jest, how do you feel about "Slack" then? One can argue it makes the product more memorable.