| ▲ | zelphirkalt 7 hours ago |
| 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 24 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. |
| |
| ▲ | x0x0 a few seconds ago | parent [-] | | I find it best when I need a calculator to understand security settings. 604800 here we come |
|
