Or better, get them all in the same units. I am human, but those dates; to me "4 years ago" scans as a shorter time than "28 days ago" unless I really concentrate.
Thanks,
Doug
Related
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
I need to alternate between 2 tasks every day, and I need a simple algorithm to know which task I need to do.
I need to be able to run this algorithm by head, using simple general knowledge (like day of week, day of month, etc), and it must not rely of which task has been done the previous day (because I have a crappy memory).
I have tried checking for parity in a combination of day of week / day of month / # of month, etc, but couldn't find a suitable system: day of week have 2 consecutive odd numbers, same goes for day of month every so often.
I am afraid that this is impossible: if you can't remember what you did the day before, any other procedure will require more mnemonic effort.
remember what you did on January first (or another date),
remember the parities of the cumulated months: oeoeoeooeoe or ooeoeoeeoeo for a leap year,
add the cumulated parity of the month before* to the parity of the day,
add that to the parity of the first task.
E.g. if A on January 1st 2022, then on March 17, 2022: e + o = o gives B.
*In January, use even.
You can also state the month parity rule as: until August inclusive, use the co-parity of the month number; then use the parity. But for a leap year, change that parity after February (excluded).
I need to be able to run this algorithm by head
So, you don't need to take help of Computer science. You can use cognitive human ability to map a thing to another thing.
Note: This need not make sense to everybody though, if you are thinking out of the box.
Map task 1 as God's day.
Map task 2 as Devil's day in your brain.
This should be simple just like day and night.
Now, remember that devil's evil karma is always burnt by God the next day and that devil never learns his lesson. So this way, alternating would be easy.
Friends Episode snippet on Youtube
Just count the number of days in between your date and a given "zero" one...then use parity.
Take number of seconds (or milli, or whatever) since EPOCH (common zero for date and time), divide (integer division) by 60x60x24 (or 1000x60x60x24, or what is appropriate), you then get the number of days since EPOCH.
----EDIT----
Example: Got 1653910695 seconds since EPOCH (at the time of my experience). Dividing it by 60x60x24 give 19142 days. To morrow it will give 19143, etc.
<?php
$day = Date('j');
$previous_day = date('j', strtotime("-1 days"));
if($day%2==0 OR $previous_day%2!=0)
echo "Task 1";
}else{
echo "Task 2";
}
?>
I want to find the "same day of the week last year". I'm sure that question is going to have litany of subtleties that I've not yet begun to think about but I believe this question is likely a common one.
Here are a few use cases where someone might want to use this algorithm:
Example 1
I'm a manager at a Walmart. I want to find out how many kitten mittens I sold the same day last year. I know that kitten mitten purchases are closely related to day of week and week of year. Thus I want to know "how many kitten mittens do I need to stock for tomorrow "the first Tuesday in January".
Example 2
I'm a nurse at a hospital. I want to determine how many patients are coming in each day next week so I can better align staff with bed demand. I know that there are strong trends with how many patients arrive at the hospital by day of week, and I want to see how many patients we had "the third Friday of November" last year.
I feel like this is a standard problem people have to have come across. Is there a best approach to this challenge? I can imagine issues where in the current year there are five Fridays in say November, and the last year there were only four, so you would not be able to report in that manner.
What is a language-independent (although if you're curious, I would be implementing this in M) approach to this algorithm?
There is a function that returns week day number. In Cache it's $zd(date,10), in GT.M there should be similar one. All you need to do is to correct your date using this function:
set currentDate=+$h
set currentWeekDay=$zd(currentDate,10)
set dateAboutYearAgo=currentDate-365
set weekDayAboutYearAgo=$zd(dateAboutYearAgo,10)
set sameWeekDayAboutYearAgo=dateAboutYearAgo-weekDayAboutYearAgo+currentWeekDay
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.
From this online calculator: http://homer.freeshell.org/dd.cgi using its data I've successfully written a working version, however its data is limited to years 1500 to 2600. I want to modify (and make a better one) so that I can calculate for any year > 2600.
Referring to Table X, is there actually a formula to calculate the base doomsday for all base centuries (above 2600)?
I've tried working it out myself by putting centuries higher than this e.g. 2700 gave me a base doomsday of '00', 2800 gave '02;, 2900 back to '00' again...
Help appreciated.
As I understand it, that page's “Base Doomsday” is just an offset to allow for the four-hundred-year cycle of leap day calculations. So, you can extend it indefinitely into the future simply by adding blocks of four centuries.
Are there any other calculators out there that do this?
Two common methods for calculating the day of the week
given a date are Doomsday, which you are using,
and Zeller's Congruence
www.merlyn.demon.co.uk provides
some really interesting information on date/time calculations, various calendar
systems and significant dates as they relate to calendar/date calculations.
The calculator at this link http://homer.freeshell.org/dd.cgi is the best in terms of explaining doomsday algorithm cleanly and clearly for human, with one little caveat.
If you input 2/29/1900, it would say it's a Thursday. Well, there is no 2/29/1900, because it's not a leap year.
Of course if your input 1/35/2016, it would "garbage-in-garbage-out" for you as well.
Imagine there are only 364 days in a year, then the day of week for each date will never change year after year, because mod(364,7)==0.
But we have 365 days a year, so the day steps forward 1 each year, that's where the second term mod(year, 7) comes from.
In addition, every 4 year, there is a leap year, which contributes to the last term mod(year, 4).
But every 100 years, you subtract a leap year, and every 400 years, you add one leap year. That's where the first term "3,2,0,5" comes in.
You see, it's all because of this leap year, and mod(365,7)==1 business.
7/11, 5to9 helps to remember table Z greatly.