|
MF_James posted:gently caress, you're supposed to push it back to dev!!! You didn't complete the finger pointing circle. As the random wandering C-Level, did you try just turning it off and on again? Like this... <walks over to breaker box> <grabs the main power breaker> <CLICK-CLACK!> <CLICK-CLACK!> <CLICK-CLACK!> <CLICK-> <horribly loud popping noise, with accompanying blue flash and sound of everything powering down hard, plus "oh poo poo im ded" noises from all the UPS units> <-CLACK!> "Hmmm. Oh well, get right on that, OK? We have a critical make-or-break-the-company sales presentation starting in 45 minutes, just arranged it this morning, figured I should drop by and give you a head's up." "Speaking of head, the mistress is waiting in my third Porsche, gotta go!"
|
#
?
May 18, 2018 17:58
|
|
|
|
| # ? Apr 16, 2024 16:34 |
|
|
96 Port Hub posted:Oh cool! This looks like a useful tip! Changing away from UTC is a mistake.
|
|
#
?
May 18, 2018 18:04
|
|
|
18 Character Limit posted:Changing away from UTC is a mistake. 
|
|
#
?
May 18, 2018 18:07
|
|
|
We have several lights that do not have light switches in the basement, as we now store product in that area of the basement and we have temp people running around that need to turn these lights on and off, some of whom do not speak very good English well... It really doesn't help that the main office breaker is on the panel between 2 of the lights. They just let the temp go and tell them not to show up for any more scheduled days and have the temp agency send someone else when they gently caress it up. "we'll find people that will know how to turn off the right light! It's not hard!" Okay so no to battery backup for the office, and no for having a light switch installed. At least this is training people to save early save often in Excel!
|
|
#
?
May 18, 2018 18:07
|
|
|
18 Character Limit posted:Changing away from UTC is a mistake. A terrible terrible mistake that will lead to so much pain down the road which is why it's a pretty hilarious video from AWS. I almost wonder if they're getting ready to launch an Unfuck your DB as a service offering or something.
|
|
#
?
May 18, 2018 18:08
|
|
|
18 Character Limit posted:Changing away from UTC is a mistake. Anyone who doubts this needs to work with python's datetime module for a while. After a few hours you'll be converting everything to UTC just so you can compare timestamps without wanting to stab yourself.
|
|
#
?
May 18, 2018 18:10
|
|
|
xzzy posted:Anyone who doubts this needs to work with python's datetime module for a while. After a few hours you'll be converting everything to UTC just so you can compare timestamps without wanting to stab yourself. Every server should be in UTC, that doesn't mean that most people using AWS understand timezones. There's a fair amount of people in 1-2 man companies that barely understand web development using AWS. They want stuff in time their local time, and wont hear anything about best practices or why this will cause problems. When you have a large call volume of low paying customers that have poor technical skills that think their $50/month is a fortune and you better give them good service! Well you make a video so you can just send them the link instead of talk to them for 2 hours on the phone.
|
|
#
?
May 18, 2018 18:14
|
|
|
pixaal posted:Every server should be in UTC, that doesn't mean that most people using AWS understand timezones. There's a fair amount of people in 1-2 man companies that barely understand web development using AWS. They want stuff in time their local time, and wont hear anything about best practices or why this will cause problems. When you have a large call volume of low paying customers that have poor technical skills that think their $50/month is a fortune and you better give them good service! Well you make a video so you can just send them the link instead of talk to them for 2 hours on the phone. My favorite part of my job is that I have clients that have their IT in India, supported by tier 3 in UK, with servers that are IDK where. They email, saying at 1am we had this issue, here's the logs, but then they clarify which timezone the servers are in, how that relates to the time they reported the issue, and when I ask, they forward me an email from a user in Hong Kong that said "at 12pm we had an issue." It's a nightmare, and typically I just draw up on a white board a chart of all the times: USERS | SERVERS | SUPPORT UTC-5 UTC+3 UTC-1 And then I just start writing the events on the board. Otherwise its too hard to track.
|
|
#
?
May 18, 2018 19:49
|
|
|
Whenever I'm not totally sure that everybody in a conversation is in the same timezone then I use UTC for everything
|
|
#
?
May 18, 2018 20:03
|
|
|
Thanks Ants posted:Whenever I'm not totally sure that everybody in a conversation is in the same timezone then I use UTC for everything Almost like part of the name is about coordination.
|
|
#
?
May 18, 2018 20:17
|
|
|
Thanks Ants posted:Whenever I'm not totally sure that everybody in a conversation is in the same timezone then I use UTC for everything This is basically exactly why you should use UTC for everything.
|
|
#
?
May 18, 2018 20:22
|
|
|
I use EST but I specify it in everything. We're the HQ office, we're the center of the universe 
|
|
#
?
May 18, 2018 21:44
|
|
|
We used to do that at a past company, everything was London time. When we spun up US and Asian regions it caused so much trouble everything got UTC’d.
|
|
#
?
May 18, 2018 21:46
|
|
|
We had someone leave the timezone of a RDS box set to London and then force the time to what it would have been in EST. They were surprised when they got a bunch of authentication issues.
|
|
#
?
May 18, 2018 21:52
|
|
|
Thanks Ants posted:We had someone leave the timezone of a RDS box set to London and then force the time to what it would have been in EST. They were surprised when they got a bunch of authentication issues.
|
|
#
?
May 18, 2018 21:54
|
|
|
Fixing time sync issues can take so long because you just assume NTP is always in place.
|
|
#
?
May 18, 2018 22:14
|
|
|
Use of kerberos gets you up to speed on NTP real quick.
|
|
#
?
May 18, 2018 22:17
|
|
|
Jaded Burnout posted:We used to do that at a past company, everything was London time. Is this in reference to summer time or do you not get in which large city Greenwich is in?
|
|
#
?
May 18, 2018 22:27
|
|
|
Quoting GMT leaves room for mistakes when people think that whatever the time currently is in the UK = GMT.
|
|
#
?
May 18, 2018 22:46
|
|
|
ookiimarukochan posted:Is this in reference to summer time or do you not get in which large city Greenwich is in? You don’t set your time zone to gmt, you set it to Europe/London.
|
|
#
?
May 18, 2018 22:57
|
|
|
Ugh. At one point at my previous position we had: •Most Servers in UTC •Ticketing System DB in Central European Time but displayed in users local time. I eventually got an admin to change it to UTC but he refused to change the past times so there is about a month of data in CET and the rest in UTC. •Help Desk in Eastern Time •Head Quarters in Central Time •Offshore Help Desk on India Standard Time •Coding team on Pacific Time •Clients in Eastern, Central, and Mountain Time Everything was always a giant mess in reference to time. Every meeting invite caused massive conflicts and god forbid you needed India involved in anything.
|
|
#
?
May 19, 2018 00:31
|
|
|
"Office hours are 9 to 5. We allow flexible time with an understanding that you'll work the required hours to complete the work on time.... you are expected to come in early, work late, work from home, stay in for lunch, sacrifice a baby etc. if you cannot meet deadlines during regular working hours." At this point I'm "working late" all the loving time if I have any hope of catching up to any deadline given. Flexibility my loving rear end. RadiRoot fucked around with this message at 08:43 on May 19, 2018 |
|
#
?
May 19, 2018 08:28
|
|
|
Obsoletely Fabulous posted:
I find the best solution to involving India is to not involve India.
|
|
#
?
May 19, 2018 08:30
|
|
|
GPDR
|
|
#
?
May 19, 2018 08:58
|
|
|
Sprechensiesexy posted:I find the best solution to involving India is to not involve India. If only that had been an option. I once caught the India desk fudging SLA numbers by counting emails as phone calls (they were billed at different rates and had way different response times for SLAs). It got ran up the chain, lots of meetings were held, and literally nothing changed. No one got fired, they kept reporting those numbers up their chain of command, etc. As far as I know they are still doing it.
|
|
#
?
May 19, 2018 15:02
|
|
|
Obsoletely Fabulous posted:If only that had been an option. I once caught the India desk fudging SLA numbers by counting emails as phone calls (they were billed at different rates and had way different response times for SLAs). It got ran up the chain, lots of meetings were held, and literally nothing changed. No one got fired, they kept reporting those numbers up their chain of command, etc. As far as I know they are still doing it. We are a new department so we have some Indians over to show us the ropes, but since their advice ranges from obvious to terrible they are now just sitting at their desks getting ignored for work related things. It's a good arrangement now.
|
|
#
?
May 19, 2018 15:52
|
|
|
One of our hardware vendors has outsourced at least some of their support to India. The quality's dropped from "generally competent" to "oh god, what?" I wasn't aware you could describe to the signal strength of an optical fibre SFP as "electrical power", but that's the terminology they used in the ticket.
|
|
#
?
May 19, 2018 16:05
|
|
|
Obsoletely Fabulous posted:If only that had been an option. I once caught the India desk fudging SLA numbers by counting emails as phone calls (they were billed at different rates and had way different response times for SLAs). It got ran up the chain, lots of meetings were held, and literally nothing changed. No one got fired, they kept reporting those numbers up their chain of command, etc. As far as I know they are still doing it. This drives me insane. We have contractual agreements on what is to be delivered. Oh, you decided not to deliver that thing? Oh well, guess we are just going to accept it as an immutable fact of life! I don't like messing with people's money, I don't like to go after people's jobs, but at some point chronic failure to fulfill a contract is a problem that needs addressing.
|
|
#
?
May 19, 2018 17:01
|
|
|
guppy posted:This drives me insane. We have contractual agreements on what is to be delivered. Oh, you decided not to deliver that thing? Oh well, guess we are just going to accept it as an immutable fact of life! Yeah. At some point the client is going to request an audit or look at the reports and poo poo will fly. Wouldn’t be the first lawsuit over billing they will be involved with.
|
|
#
?
May 19, 2018 17:08
|
|
|
anthonypants posted:Well, we've got five retention folders in your Outlook Inbox: _01 Year, _05 Years, _10 Years, _20 Years, and Permament. It's up to you and your department to decide which e-mail goes in which folder. You can create all the subfolders you want, but everything will get stored in the archive. E-mails in your inbox get backed up silently, and are deleted after 90 days. If you want to look at e-mails older than 90 days, or you want to make sure an item has been archived, you have to go into the archive. You forgot the oh btw even though we set your deleted items retention policy to 90 days, you also have a deleted items secondary bin that is also 30 days, and while you might of thought you could make this more than 30 days because the GUI says you can, you will never set that thing to more than 30 days even though you followed some bloke's instructions that swore you could do it in Powershell.
|
|
#
?
May 19, 2018 21:20
|
|
|
Dang, that's an old post.
|
|
#
?
May 20, 2018 00:42
|
|
|
Servers, logs, services, etc should all run on UTC, translation to local should happen at the client. Aaaaaaaaaaand go.
|
|
#
?
May 20, 2018 00:44
|
|
|
Paladine_PSoT posted:Servers, logs, services, etc should all run on UTC, translation to local should happen at the client. Aaaaaaaaaaand go. This should be enforced with a GDPR-style “x% of global revenue off the top” penalty. E: With increasing multipliers based on hours of divergence. EE: The absolute value of the hours of divergence, obviously. EEE: Rounded up. gently caress off, India. EEEE: You think anyone is impressed by your poo poo, Nepal? Schadenboner fucked around with this message at 02:01 on May 20, 2018 |
|
#
?
May 20, 2018 01:34
|
|
|
anthonypants posted:Dang, that's an old post. Do you think we'll have to wait another five years before he replies to this?
|
|
#
?
May 20, 2018 04:11
|
|
|
Mr. Fix It posted:Do you think we'll have to wait another five years before he replies to this? Lots of beer might of been involved today.
|
|
#
?
May 20, 2018 04:50
|
|
|
I was really hoping you were reading through the thread opening replies in new tabs so we could enjoy random replies to posts from years ago.
|
|
#
?
May 20, 2018 05:47
|
|
|
Half the jira plugins we use just ignore timezones and do whatever they like. I have a dashboard widget that's supposed to show me bookings for today and it shows me yesterday's until midafternoon. We pay for it too.
|
|
#
?
May 20, 2018 07:42
|
|
|
xzzy posted:It's amazing the internet works at all. Pretty much...
|
|
#
?
May 20, 2018 15:50
|
|
|
This is awesome. No kidding this is the best thing I’ve read this week.
|
|
#
?
May 21, 2018 01:20
|
|
|
|
| # ? Apr 16, 2024 16:34 |
|
|
Looking at other people's code is like staring into the abyss. I've gotten lucky the only production code I've looked at was written by our senior dev or approved by him, and he's good, but I did code reviews in college a bunch and it's the worst.
|
|
#
?
May 21, 2018 02:16
|
|