Duration::from_days was proposed but consensus was not reached as “day” is somewhat complicated as that sometimes can be 23 hours or 25 hours due to daylight savings or 23:59 due to leap seconds shenanigans.
That sounds like an irrelevant problem though. A duration is explicitly not concerned with daylight savings at all, I’ve always thought of it as the amount of actual time (i.e. from a monotonic clock) that has elapsed between two absolute times. So a time diff between noon on daylight savings change day and the day prior would either be 23 or 25 hours, not exactly equal to Duration::from_days(1). There’s no time zone or even year context for Duration::from_days(1), so it should always be defined as a naïve calculation involving fixed definitions for hours per day and seconds per hour.
Years are a bit more controversial, to the point where 365 days and 365.24 days are both acceptable in different contexts, and that latter value could change in the very long term (millions of years). But I think up to days, most can agree that the value assumes exactly 24 hours and is completely separate from the idea of wall clocks changing based on local law.
Now, if we want to support “logical” time math, add that to the date/time methods likelogical_add(Duration) that adds/subtracts daylight savings hours and leap seconds as needed so if you add a multiple of 24 hours, you’ll get the same wall clock time just on a different day. Maybe chrono does that, IDK, but it would be nice to have day resolution supported at the stdlib level for simple cases where I’m looking for day chunks. It’s not a big deal, and Duration::from_hours(24) is plenty readable.
so it should always be defined as a naïve calculation involving fixed definitions for hours per day and seconds per hour.
Well… that’s your opinion. But other people disagree and say that this could be confusing. But I won’t rehash the whole debate, you can read it here instead: https://github.com/rust-lang/rust/issues/120301
As long as it’s documented well, I don’t think it should matter. If it doesn’t do the thing you expect, don’t use it. I’m assuming there’s almost a 1:1 association between devs who will use Duration::from_days() wrong and devs who would make their own constants and use them wrong, so the least harmful approach is to make them available and document them clearly.
But yeah, this topic has been beaten to death and I’m mostly whining about a bit of typing, which is now substantially less with Duration::from_hours() being stabilized. I’m happy they stabilized minutes and hours, and I’m hoping they stabilize days at some point.
Then make it explicit, e.g. Duration::from_days_monotonic(...) . I’m also fine with just having constants, but those are nightly only. I want a way to clearly express durations in terms of days, and constants and functions are clearer than comments.
I want a way to clearly express durations in terms of days
The argument here is that expressing durations in terms of days is a bad idea because “day” does not really convey a very precise duration, as it is not always 24 hours.
Maybe you won’t be confused by Duration::from_days right now, but maybe a junior dev before they get their coffee, or even the senior dev on code review might miss stuff like that.
But a day does have exactly 24 hours, at least when using Unix timestamps. Leap seconds aren’t accounted for in a Unix timestamp, and Unix timestamps assume UTC timezone, which doesn’t have daylight savings.
If you don’t make a “from_days()” or “DAYS” constant, people will make their own and they’ll be wrong in exactly the same way as if that function or constant was defined in the stdlib, but at least in the stdlib, you have the opportunity to centralize the documentation for it and maybe educate that junior dev before they make a mistake.
They’re also a problem for adding seconds to system times, since one second duration could mean two seconds wall clock time. As mentioned in discussions, we accept this for seconds, but not daylight savings, which is odd IMO because leap seconds are more “real” than daylight savings.
Ideally, Duration should always represent multiples of logical seconds, and they only make sense in the context of a clock, either monotonic or system. There should be specialized functions for translating between the two (e.g. SystemTime::add_monotonic(Duration) and SystemTime.sub_monotonic(SystemTime)), which would account for leap seconds and daylight savings.
But all of that can live in an external crate like “chrono”. I just want a way to clearly communicate intent. In my case, I’m writing a ping test tool to find out how often my internet drops and I want to print logs hourly (make sure it’s still running) and daily (longer term logging purposes). This use case doesn’t need exact precision, it just needs to print roughly on a schedule (I’m running for a week or two, not multiple years). If I do actual time math, I’d use a specialized crate with clear documentation, but for something quick and dirty, I’d prefer to use the stdlib.
Duration::from_days was proposed but consensus was not reached as “day” is somewhat complicated as that sometimes can be 23 hours or 25 hours due to daylight savings or 23:59 due to leap seconds shenanigans.
That sounds like an irrelevant problem though. A duration is explicitly not concerned with daylight savings at all, I’ve always thought of it as the amount of actual time (i.e. from a monotonic clock) that has elapsed between two absolute times. So a time diff between noon on daylight savings change day and the day prior would either be 23 or 25 hours, not exactly equal to
Duration::from_days(1). There’s no time zone or even year context forDuration::from_days(1), so it should always be defined as a naïve calculation involving fixed definitions for hours per day and seconds per hour.Years are a bit more controversial, to the point where 365 days and 365.24 days are both acceptable in different contexts, and that latter value could change in the very long term (millions of years). But I think up to days, most can agree that the value assumes exactly 24 hours and is completely separate from the idea of wall clocks changing based on local law.
Now, if we want to support “logical” time math, add that to the date/time methods like
logical_add(Duration)that adds/subtracts daylight savings hours and leap seconds as needed so if you add a multiple of 24 hours, you’ll get the same wall clock time just on a different day. Maybechronodoes that, IDK, but it would be nice to have day resolution supported at the stdlib level for simple cases where I’m looking for day chunks. It’s not a big deal, andDuration::from_hours(24)is plenty readable.Well… that’s your opinion. But other people disagree and say that this could be confusing. But I won’t rehash the whole debate, you can read it here instead: https://github.com/rust-lang/rust/issues/120301
I’m sure it’s already been discussed to death 😅
As long as it’s documented well, I don’t think it should matter. If it doesn’t do the thing you expect, don’t use it. I’m assuming there’s almost a 1:1 association between devs who will use
Duration::from_days()wrong and devs who would make their own constants and use them wrong, so the least harmful approach is to make them available and document them clearly.But yeah, this topic has been beaten to death and I’m mostly whining about a bit of typing, which is now substantially less with
Duration::from_hours()being stabilized. I’m happy they stabilized minutes and hours, and I’m hoping they stabilize days at some point.C++ has proven (at great expense) that documenting footguns is not sufficient. At all. You have to make them impossible.
Then make it explicit, e.g.
Duration::from_days_monotonic(...). I’m also fine with just having constants, but those are nightly only. I want a way to clearly express durations in terms of days, and constants and functions are clearer than comments.The argument here is that expressing durations in terms of days is a bad idea because “day” does not really convey a very precise duration, as it is not always 24 hours.
Maybe you won’t be confused by
Duration::from_daysright now, but maybe a junior dev before they get their coffee, or even the senior dev on code review might miss stuff like that.But a day does have exactly 24 hours, at least when using Unix timestamps. Leap seconds aren’t accounted for in a Unix timestamp, and Unix timestamps assume UTC timezone, which doesn’t have daylight savings.
If you don’t make a “from_days()” or “DAYS” constant, people will make their own and they’ll be wrong in exactly the same way as if that function or constant was defined in the stdlib, but at least in the stdlib, you have the opportunity to centralize the documentation for it and maybe educate that junior dev before they make a mistake.
Leap seconds are already a problem for minutes and hours, which is probably why they weren’t added until now.
They’re also a problem for adding seconds to system times, since one second duration could mean two seconds wall clock time. As mentioned in discussions, we accept this for seconds, but not daylight savings, which is odd IMO because leap seconds are more “real” than daylight savings.
Ideally,
Durationshould always represent multiples of logical seconds, and they only make sense in the context of a clock, either monotonic or system. There should be specialized functions for translating between the two (e.g.SystemTime::add_monotonic(Duration)andSystemTime.sub_monotonic(SystemTime)), which would account for leap seconds and daylight savings.But all of that can live in an external crate like “chrono”. I just want a way to clearly communicate intent. In my case, I’m writing a ping test tool to find out how often my internet drops and I want to print logs hourly (make sure it’s still running) and daily (longer term logging purposes). This use case doesn’t need exact precision, it just needs to print roughly on a schedule (I’m running for a week or two, not multiple years). If I do actual time math, I’d use a specialized crate with clear documentation, but for something quick and dirty, I’d prefer to use the stdlib.