digitalmars.D.learn - Phobos: Determining number of hours or minutes or seconds till now
- aberba (4/4) Jan 19 2017 Using the standard library, how do a get number of hours or
- Rene Zwanenburg (3/7) Jan 19 2017 You can get a duration by subtracting two timestamps. For example:
- rikki cattermole (3/10) Jan 19 2017 As per the documentation this is wrong for anything beyond a few weeks.
- Rene Zwanenburg (6/9) Jan 20 2017 I think the documentation is talking about the units used, not
- Andrea Fontana (2/11) Jan 20 2017 Yes it is referred to unit!
- Jonathan M Davis via Digitalmars-d-learn (19/28) Jan 20 2017 Exactly. The conversion from anything smaller than a week up to a week (...
- aberba (6/23) Jan 20 2017 Actually I want a weak approximation. So 1 yr 6 months will be
Using the standard library, how do a get number of hours or seconds or minutes or days or months or years till current time from a past timestamp (like "2 mins ago")? Not with manual calculations but from Phobos functions.
Jan 19 2017
On Thursday, 19 January 2017 at 14:04:36 UTC, aberba wrote:Using the standard library, how do a get number of hours or seconds or minutes or days or months or years till current time from a past timestamp (like "2 mins ago")? Not with manual calculations but from Phobos functions.You can get a duration by subtracting two timestamps. For example: auto delta = (Clock.currTime - timeStamp).total!"seconds";
Jan 19 2017
On 20/01/2017 9:29 AM, Rene Zwanenburg wrote:On Thursday, 19 January 2017 at 14:04:36 UTC, aberba wrote:As per the documentation this is wrong for anything beyond a few weeks. Although I have no idea if that's the case implementation wise.Using the standard library, how do a get number of hours or seconds or minutes or days or months or years till current time from a past timestamp (like "2 mins ago")? Not with manual calculations but from Phobos functions.You can get a duration by subtracting two timestamps. For example: auto delta = (Clock.currTime - timeStamp).total!"seconds";
Jan 19 2017
On Friday, 20 January 2017 at 03:48:14 UTC, rikki cattermole wrote:As per the documentation this is wrong for anything beyond a few weeks. Although I have no idea if that's the case implementation wise.I think the documentation is talking about the units used, not length of the duration. The reason Duration makes this distinction is because months and everything larger have a variable length. I'm not sure though.
Jan 20 2017
On Friday, 20 January 2017 at 08:39:40 UTC, Rene Zwanenburg wrote:On Friday, 20 January 2017 at 03:48:14 UTC, rikki cattermole wrote:Yes it is referred to unit!As per the documentation this is wrong for anything beyond a few weeks. Although I have no idea if that's the case implementation wise.I think the documentation is talking about the units used, not length of the duration. The reason Duration makes this distinction is because months and everything larger have a variable length. I'm not sure though.
Jan 20 2017
On Friday, January 20, 2017 08:39:40 Rene Zwanenburg via Digitalmars-d-learn wrote:On Friday, 20 January 2017 at 03:48:14 UTC, rikki cattermole wrote:Exactly. The conversion from anything smaller than a week up to a week (and vice versa) is well-defined. A week is 7 days, a day is 24 hours, an hour is 60 minutes, etc. However, then number of days or weeks in a month is undefined as is the number of days, weeks, or months in a year. And it's certainly undefined how many hecto-nanoseconds there are in a month or year. The only way to know is to compare actual dates. A duration type that holds its value in hecto-nanoseconds (which core.time.Duration does) cannot possibly deal with units greater than weeks. When I originally proposed std.datetime, to try and deal with the problem, I had something like HNDuration, MonthDuration, and JoinerDuration (where HNDuration was the same as Duration is now, whereas MonthDuration held its value in months and JoinerDuration held an HNDuration and a MonthDuration). However, it was deemed way too complicated to be worth it (and at this point, I'm inclined to agree). Time is one of those things that seems quite simple at first but tends to get annoyingly mucky once you get into the finer details. - Jonathan M DavisAs per the documentation this is wrong for anything beyond a few weeks. Although I have no idea if that's the case implementation wise.I think the documentation is talking about the units used, not length of the duration. The reason Duration makes this distinction is because months and everything larger have a variable length. I'm not sure though.
Jan 20 2017
On Friday, 20 January 2017 at 03:48:14 UTC, rikki cattermole wrote:On 20/01/2017 9:29 AM, Rene Zwanenburg wrote:Actually I want a weak approximation. So 1 yr 6 months will be recorded as 1yr or better still the actually date. Just want to make it easy to determine "how long ago" for all recent data at client side.On Thursday, 19 January 2017 at 14:04:36 UTC, aberba wrote:As per the documentation this is wrong for anything beyond a few weeks. Although I have no idea if that's the case implementation wise.Using the standard library, how do a get number of hours or seconds or minutes or days or months or years till current time from a past timestamp (like "2 mins ago")? Not with manual calculations but from Phobos functions.You can get a duration by subtracting two timestamps. For example: auto delta = (Clock.currTime - timeStamp).total!"seconds";
Jan 20 2017