16 ms·

> However, the case for a breaking change should be a heck of a lot stronger than "we think all timestamps should have timezones". How about if you rephrase th

by derefr 3y ago

> However, the case for a breaking change should be a heck of a lot stronger than "we think all timestamps should have timezones". How about if you rephrase the case as "we've sampled codebases that use naive timestamps, and at least 50% of them had critical bugs related to mistaken assumptions made about timezones by functions used to produce vs consume those timestamps. Your code is already broken. This update just makes the compiler force you to rewrite your code in a way that makes the errors obvious and/or into type errors — and, therefore, which forces you to fix those bugs."

Wowfunhappy 3y ago
Presumably this code works for me if I'm using it. In most cases, an imperfect program I can run is better than one I can't run. Yes there are exceptions. In the ideal case, the author updates their code so it keeps working. But what if I'm not the author and know nothing about the codebase? Is forcing me to make a naïve change to get things working again more likely to remove bugs or add them? The compiler can warn me that I probably have a bug and should change my code. But it shouldn't hold the program hostage until I comply. This isn't a blanket statement in favor of permissive compilers. It's fine for the compiler to force good practices the first time. I just have a problem with the compiler going back and changing its mind later.
- derefr 3y ago
  > Presumably this code works for me if I'm using it. Sure, it all seems to work for now... and then a customer signs up from Tuvalu, and performs a billable action at 11:59PM on the last day of the month, and your whole billing system falls over because they now have a split invoice generated for next month while it's still this month. > But what if I'm not the author, or even a Python programmer? Is attempting to make a naïve change, in a code base I don't understand, likely to add or remove bugs? Anyone other than the developer of the code, shouldn't be attempting to re-pin the runtime the code depends on to one with a different major ABI version. The problem, of course, is that most programming languages don't have a concept of "pinning the allowed runtime version like any other dependency"; or of the runtime exposing an ABI version that increases for every breaking change. (This second could and should just be the SemVer major-version of the runtime; but for some reason projects aren't fans of bumping their major versions for every little breaking change. Personally I think we should "let marketing win", and just allow projects to expose an ABI version independently.)
  - deleted 3y ago
    [deleted]
  - Wowfunhappy 3y ago
    > Sure, it all seems to work for now... and then a customer signs up from Tuvalu, and performs a billable action at 11:59PM on the last day of the month, and your whole billing system falls over because they now have a split invoice generated for next month while it's still this month. Yeah, so the compiler should issue a warning and the user can decide how to proceed. If the user ignores the warning for code that is part of their company's billing system, that's on them. Computers should provide information, but ultimately leave the humans in charge. > The problem, of course, is that most programming languages don't have a concept of "pinning the allowed runtime version like any other dependency"; or of the runtime exposing an ABI version that increases for every breaking change. That's an equally fine way to handle things IMO, but the language would need to support each runtime version more-or-less indefinitely. It also still doesn't solve your problem with the customer in Tuvalu (which I think is fine, just pointing it out).
    - MrJohz 3y ago
      Fwiw, that's what's currently happening with this function, it is deprecated only, and I don't think there's a clear deadline yet on at what point it will officially get removed. So no code will stop working in the near future, and any code that does use this function will simply get a very clear warning pointing them in the correct direction.
      - Wowfunhappy 3y ago
        Yes, but the message clearly states it will be removed in the future. IMO they shouldn't do that. Deprecate indefinitely.
  - naniwaduni 3y ago
    > Sure, it all seems to work for now... and then a customer signs up from Tuvalu, and performs a billable action at 11:59PM on the last day of the month, and your whole billing system falls over because they now have a split invoice generated for next month while it's still this month. You think there's much of an overlap between systems that do time zone arithmetic with naive timestamps and ones that bill in the customer's time zone?
- eru 3y ago
  > The compiler can warn me that I probably have a bug and should change my code. But it shouldn't hold the program hostage until I comply. Well, you can keep using the old version of the interpreter / compiler?
- zelos 3y ago
  Timezone bugs are evil and crop up at the worst times, though. The last one I (knowingly) wrote wasn't spotted until the CEO tried to use our software on holiday on the day of a DST change.
- heavenlyblue 3y ago
  > Presumably this code works for me if I'm using it. In most cases, an imperfect program I can run is better than one I can't run. Yes there are exceptions. If using buggy code works for you, so will not upgrading will work for you.

by derefr 3y ago

Wowfunhappy 3y ago

Presumably this code works for me if I'm using it. In most cases, an imperfect program I can run is better than one I can't run. Yes there are exceptions. In the ideal case, the author updates their code so it keeps working. But what if I'm not the author and know nothing about the codebase? Is forcing me to make a naïve change to get things working again more likely to remove bugs or add them? The compiler can warn me that I probably have a bug and should change my code. But it shouldn't hold the program hostage until I comply. This isn't a blanket statement in favor of permissive compilers. It's fine for the compiler to force good practices the first time. I just have a problem with the compiler going back and changing its mind later.

derefr 3y ago
> Presumably this code works for me if I'm using it. Sure, it all seems to work for now... and then a customer signs up from Tuvalu, and performs a billable action at 11:59PM on the last day of the month, and your whole billing system falls over because they now have a split invoice generated for next month while it's still this month. > But what if I'm not the author, or even a Python programmer? Is attempting to make a naïve change, in a code base I don't understand, likely to add or remove bugs? Anyone other than the developer of the code, shouldn't be attempting to re-pin the runtime the code depends on to one with a different major ABI version. The problem, of course, is that most programming languages don't have a concept of "pinning the allowed runtime version like any other dependency"; or of the runtime exposing an ABI version that increases for every breaking change. (This second could and should just be the SemVer major-version of the runtime; but for some reason projects aren't fans of bumping their major versions for every little breaking change. Personally I think we should "let marketing win", and just allow projects to expose an ABI version independently.)
- deleted 3y ago
  [deleted]
- Wowfunhappy 3y ago
  > Sure, it all seems to work for now... and then a customer signs up from Tuvalu, and performs a billable action at 11:59PM on the last day of the month, and your whole billing system falls over because they now have a split invoice generated for next month while it's still this month. Yeah, so the compiler should issue a warning and the user can decide how to proceed. If the user ignores the warning for code that is part of their company's billing system, that's on them. Computers should provide information, but ultimately leave the humans in charge. > The problem, of course, is that most programming languages don't have a concept of "pinning the allowed runtime version like any other dependency"; or of the runtime exposing an ABI version that increases for every breaking change. That's an equally fine way to handle things IMO, but the language would need to support each runtime version more-or-less indefinitely. It also still doesn't solve your problem with the customer in Tuvalu (which I think is fine, just pointing it out).
  - MrJohz 3y ago
    Fwiw, that's what's currently happening with this function, it is deprecated only, and I don't think there's a clear deadline yet on at what point it will officially get removed. So no code will stop working in the near future, and any code that does use this function will simply get a very clear warning pointing them in the correct direction.
    - Wowfunhappy 3y ago
      Yes, but the message clearly states it will be removed in the future. IMO they shouldn't do that. Deprecate indefinitely.
- naniwaduni 3y ago
  > Sure, it all seems to work for now... and then a customer signs up from Tuvalu, and performs a billable action at 11:59PM on the last day of the month, and your whole billing system falls over because they now have a split invoice generated for next month while it's still this month. You think there's much of an overlap between systems that do time zone arithmetic with naive timestamps and ones that bill in the customer's time zone?
eru 3y ago
> The compiler can warn me that I probably have a bug and should change my code. But it shouldn't hold the program hostage until I comply. Well, you can keep using the old version of the interpreter / compiler?
zelos 3y ago
Timezone bugs are evil and crop up at the worst times, though. The last one I (knowingly) wrote wasn't spotted until the CEO tried to use our software on holiday on the day of a DST change.
heavenlyblue 3y ago
> Presumably this code works for me if I'm using it. In most cases, an imperfect program I can run is better than one I can't run. Yes there are exceptions. If using buggy code works for you, so will not upgrading will work for you.