The following code evaluates that the time being parsed is greater than 30 days ago.
Time.parse("2011-01-03T14:31:57Z") < 30.days.ago
=> true
Why is this true? It looks to me like the < is going the wrong way, and ought to be >. What am I missing?
30.days.ago is a time, that time being 30 days ago. You're seeing if your time is earlier than 30 days ago, and it is.
So, don't read it as "less than 30 days ago", read it as "before 30 days ago", or "earlier than 30 days ago".
> refers to being a date past or "greater than" the preceding date. 30 days ago is past January 3rd, therefor it is greater.
Related
I am trying to figure out the Prometheus query for average CPU usage for current week and last week from ONLY Monday to Friday excluding the weekends. I have come up with a query which fetches the information from last 1 hour for current time and last hour a week ago which is as below
For current last 1 h:-
1 - avg(rate(node_cpu_seconds_total{mode="idle"}[1h])) by (instance)
For over last hour a week ago:-
1 - avg(rate(node_cpu_seconds_total{mode="idle"}[1h] offset 1w)) by (instance)
Did anyone had similar requirements for finding the same from Monday to Friday please?
Given a date, is there an algorithm that can convert it to the week of the year?
Absolutely, but it gets very complicated.
In principle you should be able to divide by 60*60*24 = 86400 to get days, then follow the logic of the calendar to figure out days, weeks, years, and calculate the answer from that. There are 365 days in a year, except leap years. Leap years occur on years divisible by 4, except ones divisible by 100, but happen again on years divisible by 400. Since 2000 is divisible by 400, you can ignore the last 2 rules and you will be correct until the year 2100.
You also have to decide what a week is defined as. In the USA it is traditionally defined as Sunday through Saturday. In Europe it is traditionally defined as Monday through Sunday. But you know what day of the week 1970 started on (Thursday), and can therefore figure out the current year, what day of the week it started on, when that week started, and a little modulo 7 arithmetic gives you your answer.
That is...until you notice that actual date boundaries depend on timezone, whether daylight savings time is in effect, and other such things. This opens up a giant can of worms that everyone delegates to the Olson database. (Which itself needs multiple updates a year because some government, somewhere, tweaks their timezone rules.) And then every language and environment wraps their own date-time library around that. You are strongly advised to find and use that.
If time is represented in UTC, this is the end of the story. However in fact we also have leap seconds (27 so far, possibly a negative one coming soon). This is NOT dealt with by Olson or standard date-time libraries. All of whom try to find the most efficient way to ignore that the leap second happened, and pray that they don't crash when the next one comes. (Not a joke. Linux servers around the world crashed on Jul 2, 2012, and large companies have a variety of "time smearing" approaches to avoid it happening again.)
Only specialized tools like Frink deal with the ugliness of leap seconds in their full glory.
Assuming you already have the year, month, and day, here is the solution according to Pandas.
doy = get_day_of_year(year, month, day)
dow = dayofweek(year, month, day)
# estimate
iso_week = (doy - 1) - dow + 3
if iso_week >= 0:
iso_week = iso_week // 7 + 1
# verify
if iso_week < 0:
if (iso_week > -2) or (iso_week == -2 and is_leapyear(year - 1)):
iso_week = 53
else:
iso_week = 52
elif iso_week == 53:
if 31 - day + dow < 3:
iso_week = 1
Given UTC date and time as year, month, day, hour, minute, second, I was wondering about a pseudo-code algorithm to calculate the corresponding Unix epoch timestamp.
There are 60 seconds in a minute, 60 minutes in an hour, 24 hours in a day. So we can just use 60 × 60 × 24 = 86400 seconds per day and count the days backwards until 1970-01-01T00:00:00Z, right? Months have different numbers of days, though. So it's probably better to skip that and use 365 days per year. But then, there's leap years... and leap seconds... and more?
Does that suddenly make the algorithm as complex as dealing with timezones or is it still fairly easy to describe?
Given an arbitrary number of seconds, how can I get the number of years, months, days, hours and mins?
The algorithm should first compute the maximum number of years, then the number of months and so on...
What is an efficient way to do this?
It's mostly down to plain division. As you may know...
A minute has 60 seconds:
number_of_minutes := floor(number_of_seconds / 60)
An hour has 60 minutes:
number_of_hours := floor(number_of_minutes / 60) or
number_of_hours := floor(number_of_seconds / (60 * 60))
A day has 24 hours (at least usually... see below.)
A month has anything between 28 to 31 days.
A year has 365 or 366 days, or 365.2425 days on average.
The last two I mentioned may require you to think more about the stated problem. Either you define an "average" month, which then allows you to say "x seconds equal y average months"; or you don't convert your seconds to months at all.
(Thinking about it, if you were talking to an astronomer or alike, they would probably tell you that a day is not always exactly 24 hours, due to the occasional leap second.)
I have an idea for a story in which certain events happen repeatedly throughout the year of calendar dates that perfectly match each other for example 2011, 2005, 1994 one could replace these calendars with each other
I would like to be able to find calendar years past and future
If someone could help me please as I have no programming ability
Thanks in advance
Check Wikipedia.
You only need to compare the day of the week on which the first day of the year falls, and compare leap years and non-leap years separately (they will obviously differ). If the first day is the same and the days in the year are the same, so will the whole year be the same.
With this reduction, we need to first know what is a leap year. From wikipedia, the algorithm is
if year modulo 400 is 0
then is_leap_year
else if year modulo 100 is 0
then not_leap_year
else if year modulo 4 is 0
then is_leap_year
else
not_leap_year
Then we need to calculate the first day of the year. Before we start, we need a grounding. Let's take 2000, which starts on a Saturday. Every year we move forward, we move forward one day in the week except if the year follows a leap year in which case we move forward two days.
Let's walk through an example. 2000 starts on Saturday. 2001 starts on a Monday, 2 days later because 2000 is a leap year. 2002 starts on Tuesday. 2003 on a Wednesday. 2004 on a Thursday. 2005 on a Saturday, because 2004 is a leap year. From this we see that 2000 and 2005 start on the same day of the week, but the one is a leap year while the other is not. If we continue we'll find 2011 starts on a Saturday, and is therefore identical to 2005.
We can work backwards in similar fashion to find years in the past, or we can just choose an earlier starting year.
Dominical letter B: ... 1910 1921 1927 1938 1949 1955 1966 1977 1983 1994 2005 2011 2022 2033 2039 2050 2061 2067 2078 2089 2095 ...
Be careful about going back before 1752 and 1582, where 11 and 10 days were dropped from the calendar, respectively. see dataandtime.com. Otherwise there are exactly 14 possible calendars ... Half with a Feb 29th, half without. Each pair of calendars starts on a different day of the week. There should be an excel spreadsheet out there (its easy enough to generate one) that maps the years since 1752 into one of 14 columns.
2016 ends on the same days of the week as 1994, 2005 and 2011, but 2016 starts on Friday (leap year), while all the other years start on Saturday, therefore we need to wait until 2022 before the dates in 2011 match up again.