Comment by friendzis

25 days ago

> (Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.)

First day with javascript?

You mean first 86,400 seconds?

  • You have to admire the person who designed the flexibility to have 87239 seconds not be old enough, but 87240 to be fine.

    • Probably went with the simplest implementation, if starting from the current “seconds since epoch” value. Let the user do any calculations needed to translate three days into that measurement.

      It also efficiently annoys the most people at once: those what want hours will complain if they set it to days, thought that want days will complain if hours are used. By using minutes or seconds you can wind up both segments while not offend those who rightly don't care because they can cope with a little arithmetic :)

      Though doing what sleep(1) does would be my preference: default to seconds but allow m/h/d to be added to change that.

      8 replies →

    • I actually think it is not too bad a design, because seconds are the SI base unit for time. Putting something like "x days" requires additional parsing steps and therefore complexity in the implementation. Either knowing or calculating how many seconds there are in a day can be expected of anyone touching a project or configuration at this level of detail.

      22 replies →

    • This is the difference between thinking about the user experience and thinking just about the technical aspect

OP should be glad a new time unit wasn't invented

  • Workdays! Think about it, if you set the delay in regular days/seconds the updated dependency can get pulled in on a weekend with only someone maybe on-call.

    (Hope your timezones and tzdata correctly identifies Easter bank holiday as non-workdays)

    • > Workdays!

      This is javascript, not Java.

      In JavaScript something entirely new would be invented, to solve a problem that has long been solved and is documented in 20+ year old books on common design patterns. So we can all copy-paste `{ or: [{ days: 42, months: 2, hours: "DEFAULT", minutes: "IGNORE", seconds: null, timezone: "defer-by-ip" }, { timestamp: 17749453211*1000, unit: "ms"}]` without any clue as to what we are defining.

      In Java, a 6000LoC+ ecosystem of classes, abstractions, dependency-injectables and probably a new DSL would be invented so we can all say "over 4 Malaysian workdays"

      10 replies →

    • Why would it get pulled in over the weekend? What automatic deployments are you running if there also isn't a human working to get it out?

      Do you run automatic dependency updates over the weekend? Wouldn't you rather do that during fully-staffed hours?

    • Nah, working hours and make global assumptions of 0900-1230/1330-1730, M-F, and have an overly convoluted way to specify what working ours actually are in the relevant location(s).

  • If we're taking suggestions, I'd like to propose "parsec" (not to be confused with the unit of distance of the same name)

    That way Han Solo can make sense in the infamous quote.

    EDIT: even Gemini gets this wrong:

    > In Star Wars, a parsec is a unit of distance, not time, representing approximately 3.26 light-years

To me it sounds safer to have different big infra providers with different delays, otherwise you still hit everyone at the same time when something does inevitably go undetected.

And the chances of staying undetected are higher if nobody is installing until the delay time ellapses.

It's the same as not scheduling all cronjobs to midnight.