Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "unix timestamp"
Well, if your tests fails because it expects 1557525600000 instead of 1557532800000 for a date it tells you exactly: NOTHING.
Unix timestamp have their point, yet in some cases human readability is a feature. So why the fuck don't you display them not in a human readable format?
Now if you'd see:
vs the expected
you'd know right away that the first date is wrong by an offset of 2 hours because somebody fucked up timezones and wasn't using a UTC calculation.
So even if want your code to rely on timestamps, at least visualize your failures in a human readable way. (In most cases I argue that keeping dates as an iso string would be JUST FUCKING FINE performance-wise.)
Why do have me parse numbers? Show me the meaningful data.
Timestamps are for computers, dates are for humans.3
Just spent 15 minutes trying to explain Unix time and Y2K to a liberal arts major who wanted to know why 2038 is such a huge deal. It was technical, frustrating, and challenging. Kinda like debugging3
How to NOT handle dates!
Do not put the date to "mdy" format, today would be 050217.
Working on an intranet for some multi-billion corporation, and was wondering why events from last year were showing.
Last year's events were 28th of October, 2016, and was showing as upcoming events :)
Checked the code, and saw this. Quick fix, turned dates to UNIX timestamp, and it worked.2
semi dev related(later half)
A common and random thought I have:
A lot of units that humans use are either needlessly arbitrary or based on something weird. Like Fahrenheit. That shit is weird! 0°F is the freezing point of a water and salt solution. What a weird fucking thing to use!
But also, I like Fahrenheit more. Probably because it's what I was raised with and switching is tedious (though I'm trying. I'd like to use metric more), but also because one degree F is a smaller, more precise change. You can describe more accuracy without decimals.
On the other hand I prefer metric for length. Centimeters, and centimeters are way more precise and way less confusing than inches and .... 1/8th inches? Who the fuck decided on 1/8ths?!
Which brings me to my common thought:
If you look at a Unix timestamp, you can approximate somewhat when it happened. Knowing the current timestamp and a few reference points you can see RELATIVELY what a epoch stamp translates to. A few days ago, an hr ago, 2014ish.
This leads me to think that if we actually taught from a young age to think in epoch as a unit (not as a replacement to normal date formats but as a secondary at first) that we could just naturally read epoch time in the same manner we read dates like "28/01/2006 14:24:10 UTC"
In your brain you automatically know how old you were when that timestamp happened. What grade/job and where you lived at the time. What season it was. You know how far into the day it was, a little before lunch (or after or whatever, your time zone will vary). Now try with 1138458250. I can usually get roughly the year, and month if I really think about it, but that's it. And it takes much more effort
I'm sure there's other units we could benefit from but epoch is the one that usually brings this to mind for me.13
How do you approach generating "random" unique numbers/strings ? Exactly, when you have to be sure the generated stuff is unique overtime? Eg. as few collisions in future as possible.
Now I don't mean UUIDs but when there is a functionality that needs some length defined, symbol specific and definitely unique data, every time it does it's stuff.
TLDR STORY: Generating 8 digits long numbers so they are (deterministically - wink wink) unique is hard but Format Preserving Encryption saves the day. (for me)
I had to deal with both strings and codes today.
One was to generate shortlink word for url, luckily found a library that does exactly this. (Hashids)
BUT generating 8 digits long, somewhat random number was harder then I thought, found out on SO something like "sha256(seed) => bytes => ascii/numbers mangling" but that had a lot of collisions because of how the hash got mangled to actually output numbers and also to fit the length.
After some hours I stumbled upon Format Preserving encryption (pyffx) and man it did what I wanted and it had max 2 collisions in 100k values. Still the solution with this feels hacky af. (encrypting straddled unix timestamp with lots of decimals)6
What happens on Friday, 11 April 2262 23:47:16.855, to the Unix timestamp? It arrives to the maximum value8
So I had this JSON thingy, where I named the property containing a datetime string "timestamp".
For some reason, JS decided to convert that into a unix timestamp int on parse. Thx for nothing.6
For me it must be the really specific things in the PHP core that are kept for historic reasons, especially this:
"easter_date — Get Unix timestamp for midnight on Easter of a given year"