Since starting at Flatiron School a month ago the little things I used to dismiss in life have become more interesting. Subjects once potentially mundane now have life and excitement.
Sorting by Date in Gmail
I’ve always been frustrated that it felt so difficult to sort by date and time in Gmail. I came across an article explaining this and I was like “SCORE, I’m gonna do a blog post on Gmail tips and tricks”
Well, then this happened:
Alright so briefly, you wanna search your Gmail by date and time, you’re going to have to use something called “Epoch Time.” What the heck is Epoch Time?!
That rabbit hole begins…
Epoch Time
- Imagine counting time is done in terms of seconds only instead of the familiar Month Day, Year HourR:Minute:Second format we’re familiar with. I.e., December 25, 2016 08:00:00 (yes for many of you that time means presents, lots and lots of presents around this time).
- Also imagine your starting point for counting these seconds is January 1st 1970. This would make Christmas Day 2016 @ 8am having a time of 1,482,670,800 seconds.
Unix based systems decided to count time this way. In addition to UNIX- Linux and macOS also adapted this time convention. Most C/C++, Java, JavaScript, Perl, PHP, Python, Ruby, Tcl, ActionScript also adhere to this standard of time.
Test it out in Terminal, type: “date %s”
In fact throw “date %s” into google search:
Problems With Epoch Time
Remember the Y2K bug? We’ve got a similar issue on our hands here. When Epoch time was created it was only given a signed 32-bit integer. What does this mean you ask?
Epoch Time was given a memory allocation of 32 bits (2 to the 32nd power). However what we need to know is that the if we go over 2 to the 31st power we have an overflow and our programs will break.
Why do we care? 2**31 is exactly 2,147,483,647 and that number is exactly 2,147,483,647 seconds after 1 January 1970 which is Tuesday, 19 January 2038.
Year 2038 problem (aka Unix Millennium Bug): The times beyond that will wrap around and be stored internally as a negative number, which these Unix, Linux, macOS systems will interpret as having occurred on 13 December 1901 rather than 19 January 2038. This is caused by integer overflow. This is not dissimilar to the Y2K Bug where dates previously had been stored from 0–99 (i.e., 1900–1999).
Database query languages, like SQL that have UNIX_TIMESTAMP() like commands will also need to be fixed. In newer operating systems Epoch time has been widened to 64 bits (293 billion years of safety).
So where does this leave us in our Gmail search by date & time?!
- Use this nifty Epoch time converter https://ctrlq.org/epoch/
- In Gmail enter “after:” epoch digits
- In Gmail enter “before:” epoch digits
- Followed these by any search terms you want included.
Lets try this. I want to find an email thread with my friend Scott between December 14th and December 18th.
- Figure out the Epoch time https://ctrlq.org/epoch/
- Dec 14th @ 8am = 1,481,720,400 seconds in Epoch time
- Dec 18th @ 8am = 1,482,066,000 seconds in Epoch time
- Search term “Scott”
Voila:
What have we learned here? That learning never ends. You start looking for an answer for one thing and it takes you down a rabbit hole of another.
P.S. There’s exactly 86,400 seconds per day so Epoch time increases that amount each day.
P.P.S. Friday, 14 July 2017, the Unix time value will be 1,500,000,000 seconds.
P.P.P.S. Currently being December 2016 we’re creeping towards 1,500,000,00 and we’re b/t 2**30 & 2**31
P.P.P.P.S Gmail also supports these commands: after: before: older: newer: older_than: newer_than: (familiar to how we’ve used mass assignment…)
P.P.P.P.P.S Here’s a really easy way without converting by time to search too: “after:2014/11/02 before:2015/11/20”
