I am writing a Google Calendar sidebar gadget to keep track of the total hours per event tag (as determined in details of the event i.e. "tags: work").
Users can change the current week, month, day they are viewing in the calendar and I want to be able to count up the hours pertaining to their current view.
I don't see anywhere in the gadget API (or any other Google Calendar API) that allows gadgets to access the currently displayed view. I have noticed that the URL has an anchor tag that looks like
g|week-2+23127+23137+23131
which corresponds to viewing Monday Feb. 23, 2015 - Sunday March 1, 2015 in week mode.
I have also noticed the following relationships:
23127 is the first day in the view
23137 is the last day in the view
23131 is the day selected in the month view (on the left of the calendar)
If there is a way to get the currently displayed view using the API, that would be ideal but I would settle for parsing the anchor tag. Unfortunately I cannot decipher how the numbers work.
Google API
The currently displayed date range can be accessed using the following call:
google.calendar.subscribeToDates(function(d) {
// do something
});
where d is a Google date range d.startTime and d.endTime being the beginning and end.
Numbers
The numbers in the URL do not correspond directly to epoch date and time. Rather, each year has 512 days associated with it and each month has 32 days. For example, February has 28 days regularly but every leap year it has 29. The calendar never has to adjust for this since it simply allots each month 32 days and comes out with a nice even number every time.
A careful examination of the date ranges displayed will also show you that if you subtract the number for December 31 from January 1 you get 130. Accounting for the beginning and the end (don't count December 31 and January 1) will give you 128.
12 * 32 + 128 = 512 -- 12 months a year, 32 days a month and a 128 gap per year
Also, for some reason January 1, 1970 has the associated number of 33 so add that to your calculations when determining dates.
This wouldn't fit in the comments, but here's how the encoding works:
The encoding scheme makes it easy to find the day/month/year from the number.
Take 23131 which yields Feb 27, 2015 (from the example in your question).
Divide by 512 and add 1970 (epoch) for the year.
23131 / 512 = 45.xxx => 45 + 1970 = 2015.
Get the remainder of that division and divide by 32 to find the month.
23131 mod 512 = 91 / 32 = 2.xxx = February
Get the remainder of that division and it's the day.
91 mod 32 = 27
Related
I just want to run a simple weekly traffic report with the Google Analytics Sheets add on. It does work fine, but I can't seem to figure out how to sort the weeks in chronological order with the jump from 2019 to 2020.
This is how it looks like
Order of the weeks
Does anybody know what Order I need to enter to have the order from week 38 - 53 and then continue with 1,2...?
Include the year as dimension and order by year and by week, like this:
year week
2019 38
2019 39
2019 40
...
2020 1
2020 2
2020 3
For multi year weekly analysis, it's better to just use the corresponding Mondays for any date for your grouping/summing/analysis than it is to use "Week Numbers"
Those mondays can be obtained by using this arrayformula, assuming your dates were in column A (A2:A)
=ARRAYFORMULA(IF(A2:A="",,FLOOR(A2:A+5,7)-5))
can it be that Google Sheets is not calculating right?
=DAYS360(DATE(2016;12;31); date(2017;1;1))
is 1 and also this is 1 but is should be 2:
=DAYS360(DATE(2016;12;30); date(2017;1;1))
Whats wrong here?
I think it is because of the formula that is set to 360 days. It is said here that DAYS360 - Days between two dates on a 360-day year. So it means that you will only have a 30 days a month not including the date 31 in the months of (Jan, March, May, July, Aug, Oct and Dec).
For example, you use this =DAYS360(DATE(2016,10,25), date(2016,10,30)) so the expected output is 5 - which is correct
If you use =DAYS360(DATE(2016,10,25), date(2016,10,31)) the expected output is 6 - because you specify the date 31.
But, if you use =DAYS360(DATE(2016,10,25), date(2016,11,3)), the output is 8 not 9 - because it did not include the date 31.
I hope I explained it clearly.
I have a client that's giving me data sets that are broken down into quarters, periods (a block of four weeks in a quarter), and weeks. I'm writing a quick reference algorithm to return the quarter, period, week given a date and year and vise versa.
Their data is always broken down into 52 weeks, where week 1 always contains Jan 1st and starts with the Monday before or at Jan 1st. This is how they handle the 365 / 7 = 52.142857 conundrum.
So, is there a gem or built in function (cweek returns 1-53), that would give me a week number based on the premise that week 1 always contains Jan 1st or do I need to design something additional?
Way 1. Date#strftime
Date.new(2016,1,1).strftime("%U").to_i + 1 # week starts with Sunday
Date.new(2016,1,1).strftime("%W").to_i + 1 # week starts with Monday
Way 2. Date#cweek
Date.new(2016,1,1).cweek % 53 + 1 # week starts with Monday
Trying to parse and XLSX file using roo gem in a ruby script.
In excel dates are stored as floats or integers in the format DDDDD.ttttt, counting from 1900-01-00 (00 no 01). So in order to convert a date such as 40396 - you would take 1900-01-00 + 40396 and you should get 2010-10-15, but I'm getting 2010-08-08.
I'm using active_support/time to do calculation like so:
Time.new("1900-01-01") + 40396.days
Am I doing my calculation wrong or is there a bug in active support?
I'm running ruby 1.9.3-mri on Windows 7 + latest active_support gem (3.2.1)
EDIT
I was looking at the older file in Excel with the wrong data - my script / console were pulling the right data - hence my confusion - I was doing everything right, except for using the right file!!!! Damn the all-nighters!
Thanks to everyone replying, I will keep the question here in case somebody needs info on how to convert dates from excel using ruby.
Also for anyone else running into this - spreadsheet gem DOES NOT support reading XLSX files at this point (v 0.7.1) properly - so I'm using roo for reading, and axlsx for writing.
You have an off-by-one error in your day numbering - due to a bug in Lotus 1-2-3 that Excel and other spreadsheet programs have carefully maintained compatibility with for 30+ years.
Originally, day 1 was intended to be January 1, 1900 (which would, as you stated, make day 0 equal to December 31, 1899). But Lotus incorrectly considered 1900 to be a leap year, so if you use the Lotus numbers for the present and count backwards, correctly making 1900 a common year, the day numbers for everything before March 1st, 1900, are one too high. Day 1 becomes December 31st, 1899, and day 0 shifts back to the 30th. So the epoch for date arithmetic in Lotus-based spreadsheets is really Saturday, December 30th, 1899. (Modern Excel and some other spreadsheets extend the Lotus bug-compatibility far enough to show February 1900 actually having a 29th day, so they will label day 0 "December 31st" while agreeing that it was a Saturday! But other Lotus-based spreadsheets don't do that, and Ruby certainly doesn't either.)
Even allowing for this error, however, your stated example is incorrect: Lotus day number 40,396 is August 6th, 2010, not October 15th. I have confirmed this correspondence in Excel, LibreOffice, and Google sheets, all of which agree. You must have crossed examples somewhere.
Here's one way to do the conversion:
Time.utc(1899,12,30) + 40396.days #=> 2010-08-06 00:00:00 UTC
Alternatively, you could take advantage of another known correspondence. Time zero for Ruby (and POSIX systems in general) is the moment January 1, 1970, at midnight GMT. January 1, 1970 is Lotus day 25,569. As long as you remember to do your calculations in UTC, you can also do this:
Time.at( (40396 - 25569).days ).utc # => 2010-08-06 00:00:00 UTC
In either case, you probably want to declare a symbolic constant for the epoch date (either the Time object representing 1899-12-30 or the POSIX "day 0" value 25,569).
You can replace those calls to .days with multiplication by 86400 (seconds per day) if you don't need active_support/core_ext/integer/time for anything else, and don't want to load it just for this.
"Excel stores dates and times as a number representing the number of days since 1900-Jan-0, plus a fractional portion of a 24 hour day: ddddd.tttttt . This is called a serial date, or serial date-time." (http://www.cpearson.com/excel/datetime.htm)
If your column contains a date time, rather then just a date, the following code is useful:
dt = DateTime.new(1899, 12, 30) + excel_value.to_f
Also keep in mind that there are 2 modes of dates in an excel worksheet, 1900 based and 1904 based, which typically is enabled by default for spreadsheets created on the mac. If you consistently find your dates off by 4 years, you should use a different base date:
dt = DateTime.new(1904, 1, 1) + excel_value.to_f
You can enable/disable 1904 date mode for any spreadsheet, but the dates will then appear off by 4 years in the spreadsheet if you change the setting after adding data. In general you should always use 1900 date mode since most excel users in the wild are windows based.
Note: A gotcha with this method is that rounding might occur +/- 1 second. For me the dates I import are "close enough" but just something to keep in mind. A better solution might use rounding on fractional seconds to solve this issue.
You're doing your calculation wrong. How do you arrive at the expected result of 2010-10-15?
In Excel, 40396 is 2010-08-06 (not using the 1904 calendar, of course). To demonstrate that, type 40396 into an Excel cell and set the format to yyyy-mm-dd.
Alternatively:
40396 / 365.2422 = 110.6 (years -- 1900 + 110 = 2010)
0.6 * 12 = 7.2 (months -- January = 1; 1 + 7 = 8; 8 = August)
0.2 * 30 = 6 (days)
Excel's calendar incorrectly includes 1900-02-29; that accounts for one day's difference between your 2010-08-08 result; I'm not sure about the reason for the second day of difference.
Delphi Xe, Win 7, System TimeZone UTC+4:0, The first day of week in system - Monday, Time is synchronised with time.windows.com
In a palette of standard components Delphi Win32 there is component MonthCalendar, at it property WeekNubers=true (display of numbers of weeks), date=now, the first day - Monday.
Shows on 19 number (today) - number of week 43.
I request number through dateutils.WeekOfTheYear(now) = returns 42.
Source (0.5 Mb) http://www.sendspace.com/file/yuz6ko
Judging by an initial code of component MonthCalendar - there like all it is true (even if not to expose the first day of week, it takes value from system parametres).
And in inquiry WeekOfTheYear it is told, that all is considered also standard ISO applied, but numbers do not coincide :(
In any way I will not understand, where one week disappears - if to look on a calendar, should be 43 and if to consider, that weeks 53 and the first concerns last year...
By the way WeekOfTheYear on 01.01.2011 too returns 52 though like should return 1...
Why distinctions and where it is correct?
Both results are correct, the difference is because the DateUtils.WeekOfTheYear function uses the ISO 8601 standard definition of a week. That is, a week is considered to start on a Monday and end on a Sunday.
Check this explanation about the Weeks Numbers in the ISO 8601 format.
If 1 January is on a Monday, Tuesday, Wednesday or Thursday, it is in
week 01. If 1 January is on a Friday, Saturday or Sunday, it is in
week 52 or 53 of the previous year (there is no week 00). 28 December
is always in the last week of its year.
Also the Embarcadero online help for the DateUtils.WeekOfTheYear function says
....if the first calendar day of the year is a Friday, Saturday, or
Sunday, then for the first three, two, or one days of the calendar
year, WeekOfTheYear returns the last week of the previous year.
Similarly, if the last calendar day of the year is a Monday, Tuesday,
or Wednesday, then for the last one, two, or three days of the
calendar year, WeekOfTheYear returns 1 (the first week of the next
calendar year).
So due which the 01-01-2011 was Saturday this week is considered the week number 52 of the previous year.
And that also explains why the week number returned for today (19-10-2011) is 42 instead of 43.
First of all, I could see no difference between the week numbers in the TMonthCalendar component and those returned by DateUtils.WeekOfTheYear(). (Monday is the first day of week on my system.) Both show 42 for the current week and 52 (not 53) for the week of 2011-01-01. (It's 53 for 2010-01-01, so maybe you just mixed that up.)
Now, as to why it's 52 or 53, but not 1, well, it's according to the definition of the first week by ISO:
First week is the week with the year's first Thursday in it.
So week number 1 in 2011 starts on 2011-01-03, and the previous one belongs to the previous ISO year.
The TMonthCalendar can treat the last week of the year as the first week of the next year, WeekOfTheYear function does not do it, hence the difference.
For example according to TMonthCalendar, 1 Jan 2012 belongs to both last week of 2011 and first week of 2012; 2 Jan 2012 is the first day of the second week of 2012.
According WeekOfTheYear function, 1 Jan 2012 belongs to the last week of 2011 only; 2 Jan 2012 is the first day of the first week of 2012.
Monday is the first day of the week for me.