Today's Excel semi-pro tip
Nov. 6th, 2023 09:34 amIt is annoying when Excel mistakenly thinks this number you just put in is a date. The converse of that is that Excel makes it *really easy* to do math on dates and times as long as your year is after 1899. (*)
Dates are integers - 0 is the imaginary date of "1/0/1900", so 1 is 1/1/1900, 2 is 1/2/1900, 3 is 1/3/1900, and so forth.
Times are decimals - 0.25 is 6 AM, 0.6666666667 is 4 PM, 0.4564318997841 is 10:57:16 AM, and so forth. (**)
I can make a column with evenly spaced time data by entering my start time in A1, entering in A2 "=A1+X/24", and then copying A2 down the column - voila, timestamps every X hours!
If I have a column A in my spreadsheet that is dates and a column B that is times, I can make column C where I literally just add 11/3/2023 and 2:00 AM and get 11/3/2023 2:00 AM.
I can find out how many days passed between two arbitrary dates by subtracting (and then probably reformatting the results as a number, because 1/17/1900 is not quite the answer I'm looking for.) Or how many hours between two arbitrary times by subtracting and then multiplying by 24. (If I need HH:MM:SS and the value is less than 1, I can just reformat the result to a time.)
...and the cool thing I do a lot: I need to calculate a volume from timestamped flow rate data. Since my flow rate is in gallons per day and my timestamps are in days (even though they look like ordinary timestamps), I can multiply the flow rate by the difference between the timestamps even if they are not equally spaced and add up the incremental totals: voila, gallons. (***)
This has been Today's Excel semi-pro tip. Go forth and calculate!
(*) any of this may or may not translate to your preferred spreadsheet platform. One hopes that it does, just in the name of interoperability.
(**) much as I hate to give Microsoft credit for anything, this is an *extremely sensible* way to handle dates for nearly any purpose. We had the Y2K bug, and Unix timekeeping (seconds since 00:00:00 1/1/1970) will overflow in January 2038. Representing time as a floating point number uses a bit more memory, but it won't run into issues related to the number being too large for an extremely long time... and it makes doing math with dates really easy for our human brains to comprehend.
(***) some of you may recognize this as a method for numerical calculation of an integral, and not the most accurate one. It is Good Enough for my purposes. It is also so much easier to do this in Excel than in FORTRAN, let me tell you...
Dates are integers - 0 is the imaginary date of "1/0/1900", so 1 is 1/1/1900, 2 is 1/2/1900, 3 is 1/3/1900, and so forth.
Times are decimals - 0.25 is 6 AM, 0.6666666667 is 4 PM, 0.4564318997841 is 10:57:16 AM, and so forth. (**)
I can make a column with evenly spaced time data by entering my start time in A1, entering in A2 "=A1+X/24", and then copying A2 down the column - voila, timestamps every X hours!
If I have a column A in my spreadsheet that is dates and a column B that is times, I can make column C where I literally just add 11/3/2023 and 2:00 AM and get 11/3/2023 2:00 AM.
I can find out how many days passed between two arbitrary dates by subtracting (and then probably reformatting the results as a number, because 1/17/1900 is not quite the answer I'm looking for.) Or how many hours between two arbitrary times by subtracting and then multiplying by 24. (If I need HH:MM:SS and the value is less than 1, I can just reformat the result to a time.)
...and the cool thing I do a lot: I need to calculate a volume from timestamped flow rate data. Since my flow rate is in gallons per day and my timestamps are in days (even though they look like ordinary timestamps), I can multiply the flow rate by the difference between the timestamps even if they are not equally spaced and add up the incremental totals: voila, gallons. (***)
This has been Today's Excel semi-pro tip. Go forth and calculate!
(*) any of this may or may not translate to your preferred spreadsheet platform. One hopes that it does, just in the name of interoperability.
(**) much as I hate to give Microsoft credit for anything, this is an *extremely sensible* way to handle dates for nearly any purpose. We had the Y2K bug, and Unix timekeeping (seconds since 00:00:00 1/1/1970) will overflow in January 2038. Representing time as a floating point number uses a bit more memory, but it won't run into issues related to the number being too large for an extremely long time... and it makes doing math with dates really easy for our human brains to comprehend.
(***) some of you may recognize this as a method for numerical calculation of an integral, and not the most accurate one. It is Good Enough for my purposes. It is also so much easier to do this in Excel than in FORTRAN, let me tell you...