| ▲ | friendzis 11 hours 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? |
|
| ▲ | notpushkin 11 hours ago | parent | next [-] |
| You mean first 86,400 seconds? |
| |
| ▲ | x0x0 10 hours ago | parent | next [-] | | You have to admire the person who designed the flexibility to have 87239 seconds not be old enough, but 87240 to be fine. | | |
| ▲ | dspillett 3 hours ago | parent | next [-] | | 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. | | |
| ▲ | Xirdus 2 hours ago | parent | next [-] | | I'm old enough to remember computers being pitched as devices that can do tedious math for us. Now we have to do tedious math for them apparently. | | |
| ▲ | dspillett 2 hours ago | parent | next [-] | | Hence the way I would do it (and have for other purposes), as stated in my final sentence. Have the human state the intent and convert to your own internally preferred units as needed. | |
| ▲ | darepublic 2 hours ago | parent | prev | next [-] | | I'm sure you would like to memorize all kinds of API instead of having something idiot proof and straightforward | |
| ▲ | moralestapia an hour ago | parent | prev [-] | | Hey that's a great joke, you made me spill my morning home-brewed kombucha. I'm going to steal that one for my JavaScript monthly developers meetup. Is it ok if I attribute it to "Xirdus on Hacker News"? |
| |
| ▲ | fc417fc802 2 hours ago | parent | prev [-] | | The one true unit of time is hexadecimal encoded nanoseconds since the unix epoch. (I'm only half joking because I actually have authored code that used that before.) |
| |
| ▲ | zelphirkalt 7 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | wongarsu 6 hours ago | parent | next [-] | | Seconds are also unambiguous. Depending on your chosen definition, "X days" may or may not be influenced by leap seconds and DST changes. I doubt anyone cares about an hour more or less in this context. But if you want multiple implementations to agree talking about seconds on a monotonic timer is a lot simpler | | |
| ▲ | woodruffw 2 hours ago | parent | next [-] | | Could you explain what you mean re: ambiguity? I understand why “calendar units” like months are ambiguous, but minutes, hours, days, and weeks all have fixed durations (which is why APIs like Python’s `timedelta` allows them). | | |
| ▲ | nightpool 2 hours ago | parent | next [-] | | The minute between December 31, 2016 23:59 and January 1st 2017 is 61 seconds, not 60 seconds. The hour that contains that minute is 3601 seconds, the day that contains that hour is 43201 seconds, etc. If you assume a fixed duration and simply multiply by 43200, your math will be wrong compared to the rest of the world. Daylight savings time makes a day take 23 hours or 25 hours. That makes a week take 7254000 seconds or 7261200 seconds. Etc. | | |
| ▲ | woodruffw 2 hours ago | parent | next [-] | | That’s what I mean by calendar units. These aren’t issues if you don’t try to apply durations to the “real” calendar. (This is all in the context of cooldowns, where I’m not convinced the there’s any real ambiguity risk by allowing the user to specify a duration in day or hour units rather than seconds. In that context a day is exactly 24 hours, regardless of what your local savings time rules are.) | | |
| ▲ | wongarsu an hour ago | parent [-] | | "exactly 24 hours" could still be anywhere between 86399 and 86401 seconds, depending on leap seconds. At least if by an hour you mean an interval of 60 minutes, because a minute that contains a leap second will have either 59 or 61 seconds. You could specify that for the purposes of cooldowns you want "hour" to mean an interval of 3600 seconds. But that you have to specify that should illustrate how ambiguous the concept of an hour is. It's not a useless concept by any means and I far prefer to specify duration in hours and days, but you have to spend a sentence or two on defining which definition of hours and days you are using. Or you don't and just hope nobody cares enough about the exact cooldown duration |
| |
| ▲ | _alternator_ an hour ago | parent | prev [-] | | Leap seconds are their own nightmare. UNIX time ignores them, btw, so that the unix epoch is 86400*number of days since 1/1/1970 + number of seconds since midnight. The behavior at the instance of a leap second is undefined. | | |
| |
| ▲ | jon-wood 2 hours ago | parent | prev [-] | | In the UK last Sunday was 23 hours long because we switched to BST, and occasionally leap seconds will result in a minute being something other 60 seconds. |
| |
| ▲ | myhf 22 minutes ago | parent | prev | next [-] | | exploiting the ambiguity in date formats by releasing a package during a leap second | |
| ▲ | sverhagen 4 hours ago | parent | prev [-] | | I came here to argue the opposite. Expressing it in seconds takes away questions about time zones and DST. I think you're incorrect to say that second are also ambiguous. Maybe what you mean is that days are more practical, but that seems very much a personal preference. | | |
| ▲ | friendzis 2 hours ago | parent | next [-] | | I understand the [flawed] reasoning behind "x seconds from now is going to be roughly now() + x on this particular system", but how does defining the cooldown from an external timestamp save you from dealing with DST and other time shenanigans? In the end you are comparing two timestamps and that comparison is erroneous without considering time shenanigans | |
| ▲ | pavel_lishin 3 hours ago | parent | prev | next [-] | | I think you misread the comment you're replying to. | |
| ▲ | BigTTYGothGF 4 hours ago | parent | prev [-] | | [flagged] |
|
| |
| ▲ | rolux 5 hours ago | parent | prev | next [-] | | > seconds are the SI base unit for time True. But seconds are not the base unit for package compromises coming to light. The appropriate unit for that is almost certainly days. | |
| ▲ | PunchyHamster 4 hours ago | parent | prev [-] | | that kind of complexity is always worth it. Every single time. It's user time that you're saving and it also makes config clearer for readers and cuts out on "too many/little zeroes on accident" errors It's just library for handling time that 98% of the time your app will be using for something else. |
| |
| ▲ | scoutt an hour ago | parent | prev | next [-] | | Well, you have 1000000 microseconds in between. That's a big threshold. | |
| ▲ | raverbashing 10 hours ago | parent | prev [-] | | This is the difference between thinking about the user experience and thinking just about the technical aspect |
| |
| ▲ | pwillia7 2 hours ago | parent | prev [-] | | wait what if we start on a day DST starts or ends???? |
|
|
| ▲ | gib444 10 hours ago | parent | prev | next [-] |
| OP should be glad a new time unit wasn't invented |
| |
| ▲ | friendzis 9 hours ago | parent | next [-] | | 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) | | |
| ▲ | berkes 8 hours ago | parent | next [-] | | > 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" | | |
| ▲ | whatisthiseven 8 hours ago | parent | next [-] | | But you know that Java solution will continue working even after we no longer use the Gregorian Calendar, the collapse and annexation of Malaysia to some foreign power, and then us finally switching to a 4-day work week; so it'd be worth it. | | |
| ▲ | nesarkvechnep 7 hours ago | parent [-] | | It probably won’t work correctly from the get go. But it can be debugged everywhere so that’s good. | | |
| ▲ | berkes 6 hours ago | parent [-] | | ... and since it was architectured to allow runtime injection-patching of events before they hit the enterprise-service-bus, everyone using this library must first set fourteen ENV vars in their profile, and provide a /etc/java/springtime/enterprise-workday-handling/parse-event-mismatch.jar.patch. Which should fix the bug for you. You can find the patch files for your OSs by registering at Oracle with a J3EE8.4-PatchLibID (note, the older J3EE16-PatchLib-ids aren't compatible), attainable from your regional Oracle account-manager. | | |
| ▲ | xorcist 3 hours ago | parent | next [-] | | And least one of those environment can contain template strings that are expanded with arguments from request headers when run under popular enterprise java frameworks, and by way of the injection patching could hot load arbitrary code in runtime. A joke should be funny though, not just a dry description of real life, so let's leave it at that. We've already taken it too far. | |
| ▲ | hluska 4 hours ago | parent | prev [-] | | This isn’t even remotely funny. | | |
|
|
| |
| ▲ | PunchyHamster 4 hours ago | parent | prev | next [-] | | In before someone thinks it's a joke, the most commonly used logging library in Java had LDAP support in format scripts enabled by default" (which resulted, of course in CVE) | |
| ▲ | myhf 19 minutes ago | parent | prev | next [-] | | There's an extra digit in your timestamp. | |
| ▲ | mikeryan 4 hours ago | parent | prev [-] | | JavaScript Temporal. Not sure knowing what a "workday" is in each timezone is in it's scope but it's the much needed and improved JS, date API (granted with limited support to date) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... |
| |
| ▲ | sverhagen 4 hours ago | parent | prev | next [-] | | 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? | |
| ▲ | ecshafer 3 hours ago | parent | prev | next [-] | | When I worked in Finance our internal Date extension did actually have Workdays that took into account Stock Market and Bank Holidays. | | |
| ▲ | tsukikage 2 hours ago | parent | next [-] | | …now imagine a list of instruments, some of which have durations specified in days/weeks/months (problems already with the latter) and some in workdays, and the user just told your app to display it sorted by duration. | |
| ▲ | brunoarueira an hour ago | parent | prev | next [-] | | Me too, it was just a constant filled with bank holidays for the next 6 years | |
| ▲ | matltc an hour ago | parent | prev [-] | | I tried to write this function in Power Query (Excel hell). Gave up after an hour or so. |
| |
| ▲ | dspillett 3 hours ago | parent | prev | next [-] | | 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). | |
| ▲ | yohannesk 9 hours ago | parent | prev [-] | | And we also need localization. Each country can have their own holidays | | |
| ▲ | rolandog 8 hours ago | parent | next [-] | | And we need groups of locales for teams that are split across multiple locations; e.g.: new_date = add_workdays(
workdays=1.5,
start=datetime.now(),
regions=["es", "mx", "nl", "us"],
)
| | |
| ▲ | mewpmewp2 8 hours ago | parent | next [-] | | Hopefully "es" will have Siesta support too. | | | |
| ▲ | zdc1 8 hours ago | parent | prev [-] | | Might be better to calculate them separately for each locale and then tie-break with your own approach (min/max/avg/median/etc.) |
| |
| ▲ | wongarsu 6 hours ago | parent | prev | next [-] | | Don't forget about regional holidays, which might follow arbitrary borders that don't match any of the official subdivisions of the country. Or may even depend on the chosen faith of the worker | | | |
| ▲ | 8 hours ago | parent | prev [-] | | [deleted] |
|
| |
| ▲ | ghurtado 8 hours ago | parent | prev | next [-] | | 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 | | |
| ▲ | latexr 8 hours ago | parent | next [-] | | > That way Han Solo can make sense in the infamous quote. They explained it in the Solo movie. https://www.reddit.com/r/MovieDetails/comments/ah3ptm/solo_a... | | |
| ▲ | binarymax 6 hours ago | parent | next [-] | | Making a whole movie just to retcon the parsec misuse in Ep IV was a choice | | |
| ▲ | latexr 5 hours ago | parent [-] | | They made a movie to make money. I doubt anyone holding the purse strings cared one iota if that bit were corrected or not. It’s not really a retcon either because they didn’t change anything. |
| |
| ▲ | slavik81 5 hours ago | parent | prev [-] | | That had more or less been the explanation in the books for decades, and even in George Lucas' notes from 1977: > It's a very simple ship, very economical ship, although the modifications he made to it are rather extensive – mostly to the navigation system to get through hyperspace in the shortest possible distance (parsecs). |
| |
| ▲ | inopinatus 4 hours ago | parent | prev | next [-] | | It was already fine, because it’s a metric defined on a submanifold of relativistic spacetime. | |
| ▲ | slowmovintarget 3 hours ago | parent | prev [-] | | Parallax arc-second -> distance. For Star Wars, they retconned it to mean he found the shortest possible route through dangerous space, so even for Han Solo's quote, it's still distance. |
| |
| ▲ | cyrusmg 9 hours ago | parent | prev [-] | | N multiplications of dozen-second |
|
|
| ▲ | vasco 7 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | 10 hours ago | parent | prev [-] |
| [deleted] |