Google Sheets sorting by time - google-sheets

So I am in charge of office hours for a class at my University. I have to send out a google form every week for the students to sign up. The way the form is sent back, the data is grouped by Name, and the times they are available are grouped by days.
To make it easier on myself, I want to group it by times. Basically, I want it so that each day/time will have its own row, and the names of the people who want the time slot would be grouped together in the adjacent column.
I already separated the groups of times so that each time has its own cell, but I cannot figure out how to regroup the data by time.
I should also mention that each session of OH is 30 minutes and that each student can only receive one session of office hours a week because of limited availability. I also need to group the sessions into blocks so that the teachers won't have idle time (basically a teacher will have office hours from 5:00-6:30 PM on Tuesday, instead of 5:00-5:30 PM and 6:00-6:30 PM on Tuesday and 8:00-8:30 PM on Thursday). Grouping the names of the people who want office hours by the times that they are available would make it a lot easier to set up that week's office hours schedule.
Here's a link to an example:
https://docs.google.com/spreadsheets/d/1fRYYNUoEcgynU9cDMoXzsyjtIir4hsRlfFYJau36a78/edit?usp=sharing

have a look at this sheet ( i have only turned on sharing temporarily, co copy this to your own drive)
Look at the "matrix choices" sheet.
I created a Matrix of students and times (which I think is better), but there is also a list of names for each timeslot on the end too.
have a play changing some of the 1's (sessions applied for) to "G" (short for Granted). Ive set up some conditional formatting and data validation.

Related

I need to be able to count by hour the first iteration of each unique story

I get data from our CMS that shows all actions of staff within that system.
My challenge is to be able to show in a chart only the first iteration of each story as published and the hour in which it occurred.
A single story can be published multiple times during a day.
Using countuniquesif I can get the number of unique stories per hour by using:
=COUNTUNIQUEIFS(Sheet0!I2:I60000,Sheet0!G2:G60000,"NL_Stories/Ready",Sheet0!E2:E60000,"Webpub",Sheet0!B2:B60000,"08")
=COUNTUNIQUEIFS(Sheet0!I2:I60000,Sheet0!G2:G60000,"NL_Stories/Ready",Sheet0!E2:E60000,"Webpub",Sheet0!B2:B60000,"09")
Etc
However, if that story is published in the period from 8am-9am (08 in column B), if it is published again between 9am-10am (09 in column B) it will be counted again.
How can I limit this to just the first time it is published and excluded in any of the other hours.
I have attached a spreadsheet with two tabs, one with the raw data and two with what I currently do.
Any assistance appreciated
https://docs.google.com/spreadsheets/d/1V-kZyUUfXtaf6pMYDCxNSUjjWclOrUcW2Pk2y678RZo/edit?usp=sharing

How do I get the nearest past date in a range for each entry in another list?

I collect customer feedback for my education business and add it to a Google Sheet. The feedback data has a submission date (A2:A) and some satisfaction metrics, which I visualize in a Google Data Studio dashboard.
The problem is that I want the feedback per cohort, but not everyone fills in the feedback form on the same day. I have a list of all courses with their respective dates (Cohorts!A2:A), and I want to assign each feedback submission to their respective cohort in a new column. It would be nice to also match it to the specific course type and country, but for now matching the cohort date would suffice.
I've tried using VLOOKUP and ARRAYFORMULA to go through the feedback dates and get the nearest past date to take it as the "course date" for that student. All the solutions I've tried either only take a single date or TODAY as a reference, but I have a whole list I'd like to fill in.
From my understanding, you are trying to round the timestamp, then match it to your course table?
To round a timestamp to a date:
=INT($A2)
When doing lookups like you're describing, I frequently end up calculating the nearest week as well - this formula returns the Sunday of the week start. Figured it might be helpful.
=text($A2+CHOOSE(WEEKDAY($A2),0,-1,-2,-3,-4,-5,-6),"m/d/yyyy")

Algorithm for tracking changes in value over time

I am writing a rails app that deals with product inventory. I would like to include the following features, and am struggling with developing an efficient algorithm:
View stock history (how many were in stock on each date)
Quantity removed from warehouse, and quantity added to warehouse over specific periods of time
Amount of time the product was out of stock in any given period
My questions are as follows:
What is the best way of tracking changes? In addition to my Products
table, should I create another table called
HistoricProductQuantities, and insert a new record each time there
is a change in the quantity?
What number should I track? The historic stock quantity (i.e. 50 in
stock on this day, 24 in stock on that day), or the CHANGE in stock
quantity i.e. -5 (5 sold) or 15 (15 added to inventory)? Or do I
track both in separate tables?
Thanks for your help.
First of all I recommend implementing Date Dimensions on your application, as it seems like you will be doing a lot of Time related calculations. Search on Google for date dimensions as it's beyond the scope of your questions. That said, I believe it will be of great benefit for your app to implement and use date dimensions.
As far as your direct questions go:
What is the best way of tracking changes? In addition to my Products table, should I create another table called HistoricProductQuantities, and insert a new record each time there is a change in the quantity?
Yes you could do this, I would probably call it HistoricProductSnapshot and keep track of the product activity in there on daily basis. With this information as well as time dimensions you could do calculations such as "how many of Product X Did we have 5 days ago or a month ago etc etc."
What number should I track? The historic stock quantity (i.e. 50 in stock on this day, 24 in stock on that day), or the CHANGE in stock quantity i.e. -5 (5 sold) or 15 (15 added to inventory)? Or do I track both in separate tables?
I do not have experience writing inventory control software but I believe with the Snapshot table I mentioned on the question above you would only have to keep track of quantities per day. The Change in product counts could then be calculated from your snapshot table. You could for example have a function that will output the product amount in a given time range as an array. Example: From March 1 to March 7 these were the stock amounts for Product Y [45,40,39,27,22,45,44].
Hope that helps. As I said I am not a product inventory guy but I have worked with Point of Sales Systems and the procedure above should give you a could enough start for what you are trying to do.
This gem could be usefull for tracking changes in models https://github.com/collectiveidea/audited
Keep the data raw. I would personally create a new data entry every day, displaying how much items you have in stock per day. Or you can make the interval much shorter, such as every 12 hours.
For our particular use case:
We had a table called Days, which had a many to many relationship with products, and each "relationship" will have a value called quantity (to keep track of quantity of product per day). Additionally per relationship, we had another value for the relationship with transactions (a one to many relationship) that has the entries for the time of transaction and remaining stocks.
I would personally advise you to use the quantity of stock as the raw data, as it will enable you to gather the data such as how much items were removed during a certain transaction, when the item was out of stock and when it became in stock, all through the data. When you have data in which you need to perform statistical calculations on, it's best to store this data as raw values (quantity of the item).

Handling change of grain for a snapshot fact table in a star-schema

The question
How do you handle a change in grain (from weekly measurement to daily measurement) for a snapshot fact table.
Background info
For a star-schema design I want to incorporate the results of a survey as a fact (e.g. in week 2 of 2015 80% of the respondents have responded 'yes', in week 3 76% etc.)
This survey is conducted each week, and I only have access to the result of the survey (% of people saying yes this week) and not to the individual responses.
Based on (my interpretation of) Christopher Adamson's "Star Schema: The complete reference" I believe I should use a snapshot fact table for these kind of measurements.
The date dimension for this fact should be on the week-level, and be a conformed rollup of a more fine-grained date dimension for other facts in other stars that take place on a daily basis.
Here comes trouble
Now someone decides they want to conduct these surveys daily instead of weekly. What is the best way to handle this? Some of the options I'm currently considering:
change the week dimension to a daily one, and fake the old facts as if they happened on the last day of the week.
change the week dimension to a daily one, and add 7 facts for each weekly one.
create a new star, with the daily fact and dimension and treat the old one as an aggregate.
I'd appreciate any input. Please tell me if my logic is off, or my question is not clear :)
I'm not convinced that this is a snapshot. Each survey response represents a "transaction".
With an appropriate date dimension you can calculate the Yes/No percentages, rolled up by week.
Further, this would enable you to show results like "Surveys issued on a Sunday night get more responses", or "People who respond on Friday are more likely to answer 'Yes'". (contrived examples)
Following clarification, this does look like a periodic snapshot. The example of a bank account balance is often used to describe a similar scenario.
A key feature of a periodic snapshot is that every combination of every dimension should be present. If your grain is monthly, then every month you record the fact, even if it has not changed from the previous month.
I think that is the key to your problem. Knowing that your grain may change from weekly to daily, make your grain daily. It does mean you'll be repeating the weekly value on every day of the week, but that is a true representation of your knowledge of the fact; on Wednesday you only knew that its value was the same as Monday.
If you design your ETL right, you won't need to make any changes when the daily updates begin.
Your second option is the one I'd choose in your place.

Rails - handling multiple different time zones on the same request

I'm looking to display data across more than one time zone in the same view in a Rails app for a time and attendance system. A bit of context:
We make electronic time clocks. People but them in their businesses. Staff clock in and out of work and it records their hours.
The time clock pushes the time that someone clocked in/out to our API as a unix time (for example, our Javascript time clock implementation grabs the clock in time like so: moment().unix()). The API then stores this in a Postgres database as a timestamp without time zone.
When a user logs in to the site, an around_filter sets the appropriate time zone for the request based on a setting for this user's organisation.
The problem occurs if we have an organisation that spans multiple time zones. For example, a business that has an office in every Australian capital city will span three time zones (more during DST). However, there will be one person in a central office who will need to check data across the organisation - we'll call them our manager.
Suppose our manager is based in Sydney, and it's 11am. They manage three offices - one in Sydney, one in Brisbane (an hour behind Sydney during DST), and one in Adelaide (half an hour behind Sydney during DST). Staff clocked in at the three offices at 9am in their local times. So, on the manager's dashboard, all the times of the clock-ins should show up as 9am. However, the current implementation (using an around_filter) will show the times as 9am, 8am, and 8:30am, respectively, because they will be offset using the Sydney time zone.
There is a layer of filtering applied to staff from different cities, so it is possible to tell the system that person A is from Sydney, person B is from Adelaide, and person C is from Brisbane. The issue - which I'd like advice on - is how best to get Rails to display offset to different time zones as efficiently as possible.
Bonus credit: as well as showing times, we also need to read input. For example, someone may have clocked in 5 minutes early, and their timesheet needs to be corrected. If a local manager (ie. someone in Brisbane) corrects the timesheet for a Brisbane employee then that should be relatively easy to manage - given we know they are in Brisbane, we can just set the request's time zone to Brisbane and let ActiveRecord do the offsetting for us. But if the general manager (who is based in Sydney but manages all time zones) wants to make the change, then we need to be able to correctly convert their input back into UTC based on their time zone. Any suggestions on how best to do this would be wonderful.
Concrete example of the issue
In my database, my clock_ins table looks like this:
user_id (integer) | time (timestamp without time zone)
------------------|-----------------------------------
1 | "2012-09-25 22:00:00.0"
2 | "2012-09-25 22:30:00.0"
3 | "2012-09-25 23:00:00.0"
And my users table looks like this:
user_id (integer) | time_zone (varchar)
------------------|-----------------------------------
1 | "Sydney"
2 | "Adelaide"
3 | "Brisbane"
(this is a simplification, in reality there is another join between a user and their time zone)
If we apply each user's time zone to the time of their clock in, we find they are all at 9am local time. ie. 2012-09-25 23:00:00.0 at UTC is 2012-09-26 09:00:00.0 in Brisbane (+1000). The general approach in Rails is to use an around_filter to set the time zone for a request; if I did that here, each of the times would be displayed half an hour apart, which is not correct. So I'm looking on advice on best practices when working with times from various zones.
The simplest way I can see is to use the Time.use_zone method when rendering your times. e.g.
Time.use_zone('Sydney') { Time.current }
Time.use_zone(person.office.time_zone) { person.clock_ins.last.time_stamp }
This "Allows override of Time.zone locally inside supplied block; resets Time.zone to existing value when done."

Resources