Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
People complaining "oh I always have trouble figuring out if the clock goes forwards or backwards in October"
Bitch please, I'm dealing with 12 databases, with SQL dates as local timezone timestamps, and an influxDB in UTC. I'm dealing with a backend server configured in CEST and a middleware layer configured in Pacific time, and a hundred functions which try to keep everything straight because no one dares to migrate it all to UTC at this point.
In the whole argument about DST you hear about sleep psychology, electricity bills and farmers.
But what about me, the poor database administrator? What about all these ugly legacy systems, what about all the UX designers trying to fix time input pickers?
I spend 2 months a year in agony having nightmares of rips and folds in the flow of time. DAYLIGHT SAVING DOESN'T FUCKING MAKE SENSE HOW CAN TIME EXIST TWICE?17 -
--- GitHub 24-hour outage post mortem ---
As many of you will remember; Github fell over earlier this month and cracked its head on the counter top on the way down. For more or less a full 24 hours the repo-wrangling behemoth had inconsistent data being presented to users, slow response times and failing requests during common user actions such as reporting issues and questioning your career choice in code reviews.
It's been revealed in a post-mortem of the incident (link at the end of the article) that DB replication was the root cause of the chaos after a failing 100G network link was being replaced during routine maintenance. I don't pretend to be a rockstar-ninja-wizard DBA but after speaking with colleagues who went a shade whiter when the term "replication" was used - It's hard to predict where a design decision will bite back and leave you untanging the web of lies and misinformation reported by the databases for weeks if not months after everything's gone a tad sideways.
When the link was yanked out of the east coast DC undergoing maintenance - Github's "Orchestrator" software did exactly what it was meant to do; It hit the "ohshi" button and failed over to another DC that wasn't reporting any issues. The hitch in the master plan was that when connectivity came back up at the east coast DC, Orchestrator was unable to (un)fail-over back to the east coast DC due to each cluster containing data the other didn't have.
At this point it's reasonable to assume that pants were turning funny colours - Monitoring systems across the board started squealing, firing off messages to engineers demanding they rouse from the land of nod and snap back to reality, that was a bit more "on-fire" than usual. A quick call to Orchestrator's API returned a result set that only contained database servers from the west coast - none of the east coast servers had responded.
Come 11pm UTC (about 10 minutes after the initial pant re-colouring) engineers realised they were well and truly backed into a corner, the site was flipped into "Yellow" status and internal mechanisms for deployments were locked out. 5 minutes later an Incident Co-ordinator was dragged from their lair by the status change and almost immediately flipped the site into "Red" status, a move i can only hope was accompanied by all the lights going red and klaxons sounding.
Even more engineers were roused from their slumber to help with the recovery effort, By this point hair was turning grey in real time - The fail-over DB cluster had been processing user data for nearly 40 minutes, every second that passed made the inevitable untangling process exponentially more difficult. Not long after this Github made the call to pause webhooks and Github Pages builds in an attempt to prevent further data loss, causing disruption to those of us using Github as a way of kicking off our deployment processes (myself included, I had to SSH in and run a git pull myself like some kind of savage).
Glossing over several more "And then things were still broken" sections of the post mortem; Clever engineers with their heads screwed on the right way successfully executed what i can only imagine was a large, complex and risky plan to untangle the mess and restore functionality. Github was picked up off the kitchen floor and promptly placed in a comfy chair with a sweet tea to recover. The enormous backlog of webhooks and Pages builds was caught up with and everything was more or less back to normal.
It goes to show that even the best laid plan rarely survives first contact with the enemy, In this case a failing 100G network link somewhere inside an east coast data center.
Link to the post mortem: https://blog.github.com/2018-10-30-...7 -
Timezones. So, general rules are:
1. If you don't store timezone, always use and assume UTC. Databases, backends, whatever you use, all time must be kept be in UTC.
2. If you store timezones, ensure you store them everywhere and don't drop them anywhere.
3. It's always better to ignore backend server time in favor of database's `now().` Having a single source of truth makes time consistent (if it's the same database, obviously). If you combine backend time and database time, you likely get a violation of causality.
I've just spent a couple of hours investigating "weird random one-hour time drifts on updates." Guys violated all three rules above:
- they didn't store the timezone;
- their servers had inconsistent timezones. Java was in +XX., while the server itself in UTC. On one host, they forgot to put JVM in the same timezone;
- they dropped the timezone because they thought it was the same everywhere, so there was no point in serializing it.
13 -
We called it "Project Hindenburg".
A huge planning and logistics app with hundreds of screens and dozens of interwoven subfunctions, suddenly needed to be able to support multiple time zones. Our project was to retrofit every area that touched on dates or times, to allow the user to specify, and work in, any time zone.
At this point in the story I can tell whether you have had to work with time zones in code. People who haven't are butting in with something that begins, "that should be fairly simple, you just need to..." followed by some irrelevant noise that betrays their ignorance.
People who have worked with time zones are nodding in shared pain, like fellow attendees of a survivors meeting.
You see, programmers tend to think of time zones as arithmetic; in reality, they are confusing, ambiguous, chaotic, and individual. You can't translate everything into a central time zone (eg UTC) because you lose the user's intent. For example, if you schedule a meeting for 3pm and then move it to the next day, you want it at 3pm even if the clocks have changed.
Project Hindenburg ended up using the entire development staff of the company for well over a year. It smashed our release projections to rubble, made an already tangled code base completely unmaintainable, introduced mind-bending edge case bugs that reduced staff across the company to tears (literally), and led to most of the mid-level and senior developers eventually quitting (including me).
I am @fuckfuckityfuck, and that was the story of Project Hindenburg.11 -
My country just changed its time zone from UTC+3 to UTC+2.
Now I have to change the server to handle requests correctly!
PS. Probably tomorrow will be a big chaos for everyone!10 -
Oooh what I hate it..... Timezones... Who really came up with that shit? GMT, UTC, CET and garbage like that. And then also the DST crap.
Whats wrong with the same time in the whole world? Without DST or timezone garbage that just makes life harder for both developers and travellers which are going to meet someone or have something booked.18 -
My preferred stack is Rails/NginX/Postgres, or Node using the same.
I have a fair amount of material for this week's rant, but in my stack's defense, the quantity is primarily because I've been using it for so long, and I'm apparently a talented breaker. I may share other stories if the motivation arises.
However, today I ran into something definitely deserving of calling out.
The default datatype for a Date+Time column in Postgres is `datetime` which means "date+time without timezone". (while `datetimetz` instead stores the timezone).
Apparently when comparing a datetime with a datetimetz, Postgres doesn't compute the timezone difference correctly, leading to some very unexpected and confusing query results.
Today, I had a record that was both pending (expires_at > now) and expired (expires_at <= now), where now is a DateTime (with tz) literal from Rails. After half an hour's frustrated delving and baffled expressions at query results, I finally figured out that the database's math was incorrect when comparing UTC (+0) and PST (-7).
This during a semi-high-priority bugfix that's blocking for a coworker.
While Time and all of its nuances are honestly extremely difficult to handle correctly, I didn't expect Postgres to get this relatively simple part wrong.
Shame on you, Postgres.
I expected better.3 -
this just happened a few seconds ago and I am just laughing at the pathetic site that is Facebook. xD
4 years ago:
So I was quite a noobie gamer/hacker(sort of) back then and i had a habit of having multiple gmail/fb accounts, just for gaming, like accounts through which i can log in all at once in the same poker room, so 4/5 players in the game are me, or just some multiple accounts for clash of clans for donations.
I had 7-8 accounts back then. one had a name that translated to "may the dead remain in peace "@yahoomail.com . it was linked to fb using same initials. after sometime only this and 2 of my main accs were all i cared about.even today when i feel like playing, i sometimes use those accs.
2 years ago.
My dad is a simple man and was quite naive to modern techs and used to hang around with physical button nokia phones.But we had a business change, my father was now in a partnership in a restaurant where his daily work included a lot of sitting job and and casual working. So he bought a smartphone for some time pass.
He now wanted to download apps and me to teach him.I tried a lot to get him his own acc, but he couldn't remember his login credentials.
so at the end i added one of my own fake ID's(maythedead...) so he could install from playstore, watch vids on youtube and whatever.
The Actual Adventure starts now
Today, 1 hour ago:
I had completely forgot about this incident, since my parents are now quite modern in terms of tech.
But today out of nowhere i recieved an email that someone has JUST CHAINGED MY FB PASSWORD FOR ONE OF MY FAKE ACCS!?!??
what the hell, i know it was just a useless acc and i never even check my fb from any acc these days, but if someone could login into that acc, its not very difficult to track my main accs, id's, etc so i immediately opened this fb security portal and that's where the stupidity starts:
1)To recover your account they FUCKIN ASKS FOR A PHYSICAL ID. yeah, no email, no security question you have to scan your driving license or passport to get back to your account.And where would I get a license for some person named "may the dead remain in peace"? i simply went back.
2) tried another hack that i thought that will work.Closed fb help page, opened fb again , tried to login with my old credentials, it says" old password has been changed,please enter new password", i click forget password and they send an otp. i thought yes i won, because the number and recover mail id was mine only so i received it.
when i added the otp, i was first sent to a password change page (woohoo, i really won! :)) but then it sends me again to the same fuckin physical id verification page.FFFFFFFFFuck
3)I was sad and terrified that i got hacked.But 10 mins later a mail comes ,"Your Facebook password was reset using the email address on Tuesday, April 10, 2018 at 8:24pm (UTC+05:30)."
I tried clicking the links attached, hoping that the password i changed(point<2>) has actually done something to account.NADA, the account still needs a physical license to open:/
4) lost, i just login to my main account and lookup for my lost fake account. the fun part:my account has the display pic of my father?!!?!
So apparently, my father wanted to try facebook, he used the fake account i gave him to create one, fb showed him that this id already has an fb account attached to it and he accidently changed my password.MY FATHER WAS THE HACKER THE WHOLE TIME xD.
but response from fb?" well sir, if you want your virtually shitty account back , you first will have to provide us with all details of your bank transactions or your voter id card, maybe trump will like it"
-
// Time isn't converted to Customer's timezone because it's stored in the database in the time of Customer's timezone, not in UTC
GOD WHY14 -
A tutorial app that convinces everyone to adopt UTC (so I no longer have to account for time zones and/or DST in code.)3
-
GMT/UTC
IST
ACST
CST
PST
.
.
.
.
.
Man Fuck time zones, I don't even know where I belong anymore while keeping track of all of them at once.
Fuck You In The Ass Time Zone3 -
I've been using the Square REST API and I spent one hour thinking there was something wrong in my code until I f** found that THEY were not following OAuth 2 guidelines, which made their workflow incompatible with the OAuth lib I was using, so I had to mark an exception for Square's OAuth from the rest of my OAuths. Specifically, RFC 6749 Section 4.2.2 and 5.1.
However, after reading OAuth 2 guidelines, I became angry at THEM instead. The parameter `expires_in` should be the "lifetime in seconds" after the response. This will always be innevitably inaccurate, since we are not taking into account the latency of the response. This is, however, not a huge problem, since the shortest token lifetimes are of an hour (like f** Microsoft Active Directory, who my cron jobs have to check every ten minutes for new access tokens). Many workflows (like Microsoft, Square, and Python's oauthlib) have opted to add the `expires_at` parameter to be more precise, which marks the time in UTC. However, there's no convention about this. oauthlib and Microsoft send the time in Unix seconds, but Square does this in ISO 8601. At this point, ISO 8601 is less ambigious. Sending a raw integer seems ambiguous. For example, JavaScript interprets integer time as Unix _milliseconds_, but Python's time library interprets it as _seconds_. It's just a matter of convention, a convention that is not there yet.
Hope this all gets solved in OAuth 2.1 pleeeaasseee
1 -
DAYLIGHT SAVING!!
Up to this point, I was indifferent to the issue if it should be kept or not. My sleep schedule is fucked and non-routine anyway so one hour plus or minus doesn't play any role.
I got to a meeting scheduling problem, when I have 2 timestamps in variable timezones and want to calculate time difference. Both can have DST active. There is no algortihmic way to figure out. I checked SO and pytz and it's just a list of hardcoded dates when DST starts and ends. WHATHTEHELL.jpg
Not only we should abolish the DST, we should force the whole world into UTC/Zulu. And those, who refuse to adapt to UTC, will be forced to work with plain integer epoch dates.3 -
Converting server time to any given local timezone is a pain in the ass.. at least in JS.
Here's what I've got:
convertNowToTimezone = (localOffset) => {
let d = new Date();
let millis = d.getTime() + (d.getTimezoneOffset() * 60000); //convert server local time to UTC millisec
d.setTime(millis - (localOffset * 60000)); //convert UTC millisec to required local time
return d;
}
where I pass localOffset as -330 (IST offset).
Works in chrome console but gives a diff of 4min in the server side nodejs I'm running it in..
🤬🤬😡😡😡😡😡9 -
I had an interesting mystery the other day. I work in the UK, but I'm working remotely from the US for a while. First day, I made some changes, ran the tests and they failed. Weird part was the failing test was for a component I hadn't touched. I took a closer look, and realized it was a date off by several hours. The test was checking that a passed in date appears in the output. But it was creating the date by parsing a string. The library I was using defaults to local time, but the component uses UTC. So, I had inadvertently created a unit test that only passes when run from UTC. But I had never noticed before because my work is in that timezone. Yikes!
-
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 -
When the framework you're using decides to work in UTC after 5 years of using default system timezone. And instead of giving you the option to change timezone, hardcore enforces it by:
os.environ['TZ'] = 'UTC'
time.tzset()
For people who don't know python.. It basically tells your code that your system time is set to UTC (ingnoring the right timezone)
Now we get one bug after another because of this undocumented shitty change without changes in how time fields behave in different client timezones.
😒🔫
(Don't get me wrong, using UTC is logical however not in an existening application and forcing devs to rewrite all code that handles time fields)1 -
iAPPLIED CS UNIVERSITY, DAY 1 (2018-09-24)
11:00 UTC+3: Arrived at the secretary's office to complete my registration. I met quite some people; I forgot the names of some. I spent some time over there, so I took the 13:00 class instead of the 11:00 one. It's still early, so we pick whichever we want.
13:00: Procedural Programming at the Computer's lab. The computers were running Windows 8.1! 😱 I might connect to my laptop via RDP. It would be very cool. The course was about C, but the first time was just an introduction. We are going to use Code::Blocks. We were also explained the (HTTP only) web platform in which we are logged in via our passwords and submit our assignments. The professor was very nice, but this day at least was very boring. I was watching CodeMinkey cartoons, trying to solve AdLitterams.
18:00: Back for Applied Mathematics I. At the same computer lab. No lesson did happen, because we have to s learn theory stuff first (every Friday I think). Back to home.
Tommorrow is going to be a hard day...:wq1 -
FUCKING TIMEZONES. FUCKING JAVASCRIPT.
Date.parse("2019-01-01") = local time
Date.parse("2019-01-01T00:00") = UTC
Why? How's that supposed to make sense? Am I stupid? I just want UTC to be assumed for everything. Anyone? Any suggestions?4 -
Java server faces (primefaces) needs you to define shit like "DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE" or that stupid piece just assumes that every date time should be loaded as UTC timezone.
Production standard my ass nobody wants to use such verbose, outdated and logically incomprehensible piece of shit, not even at gunpoint -
So, about the devRant meetup(see previous rants), I didn't really hear anything about tomorrow, so just in case, I'm continuing with my proposal, it seemed more people were up for Sunday then Friday, so post the time you are free at on Sunday, along with your time zone(or UTC/GMT for privacy)30
-
Saving time data with timezone in the server is really headache!
Someone says keeping server time in UTC is good practice. -_- -
What the crap? Get this, I'm setting the timezone to UTC in PHP. All find and dandy, only that it gives me the wrong FUCKING date and time, like what is wrong with you xD I changed nothing since yesterday and yesterday it gave me the correct time xD2
-
Timecalculations and Datetime manipulation from UTC to locale where locale can be anything are by itself annoying but Javas Date and Calendar APIs always make me feel like "Seriously?! Fuck you! What do you want from me?! "
Argh....
Wasting so much time right now to get a fairly easy app built as showcase for new customers and continue with my life!2 -
At work thres a legacy "common" DLL, which held a helper function that's incharge of creating Slugs, it takes an MD5 of the current time stamp UTC, removing non-URLable chars, and taking the first N chars that remain then
Ngl I was impressed at first at it, but then I thought, its Uniqueness isnt guaranteed
But then again I thought, the uniqueness can be tested via a call given it's indexed anyway in DB so O(1), and if non-unique, just re-call the function. Even in the worst case scenario the hits won't be that many anyway
I didnt change the code, tho at first I was inclined to given my "it isnt proven-unique" stance but am wondering, if this is a good approach
While coolish, it seems wrong in the back of my mind somehow...1 -
!rant
Are there any worthwhile jobs were you (remotely) can code part time on the weekend. Want to make some money on top of my daily job.
Maybe it would also be possible to contribute in the afternoon (since my timezone is utc+2).
Languages of choices would be Java (preferly spring boot stuff) >> Python / JS. Any idea if that is possible?4 -
Dad woke his son up and said
"it's 7 am, wake up and get to work, you lazy shit" .
Son shouted "Don't worry , my service runs in Utc time zone"😂😂😂
Top Tags
Weekly Rant
View