Comment by x0x0
25 days ago
You have to admire the person who designed the flexibility to have 87239 seconds not be old enough, but 87240 to be fine.
25 days ago
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.
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.
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.
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"?
1 reply →
I'm sure you would like to memorize all kinds of API instead of having something idiot proof and straightforward
1 reply →
No no no, see now we just say "computer! do tedious math!", and it will do some slightly different math for us and compliment us on having asked it to do so.
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.)
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.
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
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).
12 replies →
exploiting the ambiguity in date formats by releasing a package during a leap second
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.
3 replies →
> 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.
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.
I find it best when I need a calculator to understand security settings. 604800 here we come
This is the difference between thinking about the user experience and thinking just about the technical aspect
Well, you have 1000000 microseconds in between. That's a big threshold.