I used to think this way, then it was pointed out to me that, without timezones, we’d be in a situation where Saturday starts mid-workday in some places.
Yeah, timezones are absolutely helpful from a logistics and coordination standpoint. Daylight savings time, though… That nonsense needs to be eliminated. So what if it will be dark well into morning wake hours in the winter, I’d take it over dealing with the time change twice a year.
Not sure what you mean. My position is that daylight saving time should be abolished entirely. You linked an article about a push to move permanently on to daylight saving. I pointed out how that is actually a bad idea.
I just linked it to show the rare piece of bipartisanship. I agree DLST should be done away with. As to which schedule to keep, I find it to be 6 of one and half dozen of another. The difference is just another nit pick someone will find excuses to argue over.
The difference is just another nit pick someone will find excuses to argue over
No, it isn’t. The scientific research actually suggests that keeping DST is worse than switching back and forth. I have to admit I find that confusing, since a lot of the specific studies I’ve looked at concentrate on the effects caused by the switchover itself, but the meta-analysis doesn’t mince words:
In summary, the scientific literature strongly argues against the switching between DST and Standard Time and even more so against adopting DST permanently.
There are good sides to DST, such as coming home “earlier” (by the sun clock but not by the social clock) from school or work and therefore having more hours of daylight during the free time after work. These positive effects may go beyond subjective feelings. A study has shown for example that activity increases with longer evening daylight (Goodman et al., 2014) – albeit with small biological effect sizes (≈6% difference in the daily activity between the Standard Time of the year and DST, adjusted for photoperiod). Interestingly these results of the above study were culture-specific: a significant increase was mainly observed in Europe and to some extent in Australia, while no significant effects or even slightly negative effects were seen in the United States and Brazil.
Fucking duh. This is the sticking point for me, and I am disappointed that the article doesn’t mention the effect of latitude here. Very easy for muricans to say “DST is not useful” when these fuckers never get pitch-black night before 6pm or full daylight before 6am ST.
Brussels is on the same latitude as Calgary. ST robs every office worker of one hour of useful daylight. That’s it. That’s the whole argument for permanent DST. Businesses will not change their opening hours, so permanent ST means a net loss of one active hour in the day for every office worker. Permanent DST in Europe means someone working 9-6 would not have to drive home at night for 4 months of the year and could maybe even take the dog for a walk in the evening sun.
timezones are absolutely helpful from a logistics and coordination standpoint
They’re a downside from a coordination standpoint. If everyone was on UTC, you could say “the meeting is at 04:00” and everyone, anywhere in the world, will know when the meeting is. In the real world, you have to say “the meeting is at 2pm AEST” and then someone in AEDT will have to think “oh, that’s 3pm for me”, and someone in American EST will have to convert to UTC and then convert to their time. It’s a huge pain.
So what if it will be dark well into morning wake hours in the winter
That’s not something that DST does. It would be something that switching to year-round DST would do, but permanent standard time doesn’t change winter hours at all. It can mean you might have dark mornings (especially early and late summer—after the switch to DST and before the switch back to standard time), depending on how far west you are in your time zone and how far away from the equator you are. That’s the main thing DST does: swap bright mornings for bright afternoons in summer. Which is kinda silly considering it’s done at the time of year when afternoons are already bright for the longest. It’s also very harmful to public health.
Eliminating time zones doesn’t make scheduling meetings easier it just changes the language. Instead of figuring out what time it is elsewhere you have to remember what normal working hours are, Europe, US, and Japan aren’t all going to be available 9-5 UTC. It’s just as easy to suggest a meeting at functionally midnight without time zones.
Yeah you’re absolutely right that it does create a tradeoff. My experience has just been that I’d usually consider it a worthwhile tradeoff. In general, the number of people who have to deal with setting meetings is lower than the number of people who attend meetings, especially when you take into account multinational companies.
And when you’re attending a meeting, you only care about knowing what time it has been scheduled for already. It’s in scheduling that you have to work out when is going to be best for your audience, and I’m of the opinion that the distinction between “what time is this in my time zone and their time zone?” and “where does this time sit in relation to their working day?” is net neutral. With one aspect being a strict positive and the other being a net neutral (in my opinion), I think it still wins out and becomes worthwhile.
I’d argue not every job will always be 9-5, so you still get people having to explain working hours with non-UTC timezones anyway, whereas all timezone conversions are eliminated if everyone uses UTC.
But… We have UTC already, so calculating the difference is a non-issue. If you got rid of timezones, you’d still end up creating it in all but name since the vast majority of business will be occurring during daytime hours around the world. For example, an office in Tokyo sending emails to their NYC office at 0800 UTC (currently 0400 EDT in NYC) wouldn’t end up getting answered for at least 3-4 hours when those employees started logging in. In other words, people would still be doing calculations in their heads to know when business hours are in that region, essentially recreating timezones.
As for your second paragraph, I agree, and I did have it backwards, thanks for the correction. In the summertime where I live, the sun has risen by roughly 0530 and sets around 2100. In the wintertime, the sun is rising around 0700-0730 and setting around 1630-1700 at its shortest daylight hours. Like you said, staying at standard would mean in the summertime we’d have brighter mornings, but curtains and shutters exist for a reason. Personally, I think having it still be bright out at 2030 is kind of annoying.
If you got rid of timezones, you’d still end up creating it in all but name since the vast majority of business will be occurring during daytime hours around the world. For example, an office in Tokyo sending emails to their NYC office at 0800 UTC (currently 0400 EDT in NYC) wouldn’t end up getting answered for at least 3-4 hours when those employees started logging in. In other words, people would still be doing calculations in their heads to know when business hours are in that region, essentially recreating timezones.
Not necessarily. In Teams, it shows the user’s specific hours they work as well as the time difference (this person is 2 hours behind you). All it would need is to remove the time difference and just display the time they work.
A person in Japan would just put in their signature or it would be in the application that they work from 0400 to 1200 while you still work 0800 to 1600 and you’d have your answer.
For some offices, tech like Teams/Outlook would certainly help, sure. But the majority of offices aren’t using that. But even still, people would do it regardless. Say you’re going on vacation and want to know when daylight hours are, you’d still be doing the same thing. Timezones may be annoying, but they ultimately make sense. We have a universal time for the planet powering the system, there’s really no reason to change it, in my opinion.
You obviously don’t suffer from a sensitive circadian rhythm. To that I’d say, lucky you. But there are plenty of people who do suffer. And by the time they finally get used to the time change, it’s time to change again. It’s vicious and disruptive; to more than just scheduling. It has a direct (negative) impact on physical and mental health.
Fair enough. Personally I and many others in northern Europe (and other places far from the equator) feel depressed in winter due to the highly reduced sunlight so removing DST isn’t just as obvious as “people will feel better”, because DST at least in theory helps with that.
Yeah, Seasonal Affective Disorder is a recognised medical condition and its symptoms get worse the further from the equator you live. Don’t know why folks are downvoting you for having it.
Assuming you used UTC as the shared time zone, 00:00 on Saturday would start at what is today 4pm in US Pacific Standard Time. So you’d finish work at 01:00 Saturday.
On the other hand, you wouldn’t resume work until 17:00 on Monday.
The creator of DST gets the first slap. Then the timezones asshole.
I’m planning to do a presentation at work on how to deal with dates/times/timezones/conversion/etc in the next few weeks some time. I figure it would be a good topic to cover. I’m going to start my talk by saying “first, imagine there is no such thing as timezones or DST.” And then build on that.
All in the same time? But… Then the sun might go down at noon. That doesn’t make sense…
Wait… Noon? Noooon…
The word noon comes from a Latin root, nona hora, or “ninth hour.” In medieval times, noon fell at three PM, nine hours after a monk’s traditional rising hour of six o’clock in the morning. Over time, as noon came to be synonymous in English with midday, its timing changed to twelve PM.
Sandford Fleming (the guy who invented time zones) actually made it easier.
Before timezones, every town had their own clock that defined the time for their town and was loosely set such that “noon is when the sun is at its highest point in the sky.” Which couldn’t be measured all that accurately.
If it wasn’t for Fleming, we’d be dealing with every city or town having a separate time zone.
Everyone would use UTC and a 24-hour clock rather than AM/PM.
If that means you eat breakfast at 1400 hours and go to bed around 400 hours and that the sun is directly overhead at 1700 hours (or something more random like 1737), fine. (Better than fine, actually!)
Every area keeps track of what time of day daily events (like meals, when school starts or lets out, etc) happen. Though I think generally rounding to the nearest whole hour or, maybe in some cases, half hour makes the most sense. (And it’s not even like everyone in the same area keeps the same schedule as it is now.)
You still call the period before when the sun is directly overhead “morning” and the period after “afternoon” and similarly with “evening”, “night”, “dawn”, “noon”, “midnight” etc.
One caveat is that with this approach, the day-of-the-month change (when we switch from the 29th of the month to the 30th, for instance) happens at different times of the day (like, in the above example it would be close to 1900 hours) for different people. Oh well. People will get used to it. But I think it still makes the most sense to decide that the days of the week (“Monday”, “Tuesday”, etc) last from whatever time “midnight” is locally to the following midnight, again probably rounding to the nearest whole hour. (Now, you might be thinking "yeah, but that’s just timezones again. But consider those timezones. The way you’d figure out what day of the week it was would involve taking the longitude and rounding. Much simpler than having to keep a whole-ass database of all the data about all the different timezones. And it would only come into play when having to decide when the day of the week changes over.)
Though, one more caveat. If you do that, then there has to be a longitudinal line where it’s always a different day of the week on one side than it is just on the other side. But that’s already the case today, so not really a drawback relative to what we have today.
My experience is that you start work and the next day is off so you just lock the doors and keep working, but maybe there are financial institutions without backlogs idunno.
Yeah. I figured the day-of-the-month change should definitely happen at UTC midnight. I kindof like the idea that a day of the week lasts from before I wake up to after I go to sleep. (Or at least that there’s no changeover during business hours.)
But hell. If you wanted to run for president of the world on a platform of reforming date/time tracking but planned for the days of the week to change at midnight UTC, I’d still vote for you.
You still call the period before when the sun is directly overhead “morning” and the period after “afternoon” and similarly with “evening”, “night”, “dawn”, “noon”, “midnight” etc.
Note that the Sun position is not consistent throught the year and varies widely based on your latitude.
In Iceland (and also Alaska) you can have the Sun for a full 24 hours in the sky (they call it “midnight sun”) during Summer solstice (with extremelly short nights the whole summer) and the opposite happens in Winter, with long periods of night time.
I think it still makes the most sense to decide that the days of the week (“Monday”, “Tuesday”, etc) last from whatever time “midnight” is locally to the following midnight, again probably rounding to the nearest whole hour.
Just the days of the week? you mean that 2024-06-30 23:59 and 2024-07-01 00:01 can both be the same weekday and at the same time be different days? Would the definition of “day” be different based on whether you are talking about “day of the week” vs “universal day”?
Note that the Sun position is not consistent throught the year and varies widely based on your latitude.
Good call. The definitions of “noon” and “midnight” would need to be formalized a bit more, but given any line of longitude, the sun passes directly over that line of longitude “exactly” once every 24 hours. (I put “exactly” in quotes because even that isn’t quite exactly true, but we account for that kind of thing with leap seconds.) So you could base noon on something like “when the sun is directly over a point on such longitudinal line (and then round to the nearest hour).”
Could still be a little weird near the poles, but I think that definition would still be sensical. If you’re way up north, for instance, and you’re in the summer period when the sun never sets, you still just figure out your longitude and figure when the sun passes directly over some point on that longitudinal line.
Though in practice, I’d suspect the area right around the poles would pretty much just need to just decide on something and go with it so they don’t end up having to do calculations to figure out whether it’s “afternoon” or “morning” every time they move a few feet. Heh. (Not that a lot of folks spend a lot of time that close to the poles.) Maybe they’d just decide arbitrarily that the current day of the week and period of the day are whatever they currently are in Greenwich. Or maybe even abandon the use og day of the week and period of the day all together.
Just the days of the week? you mean that 2024-06-30 23:59 and 2024-07-01 00:01 can both be the same weekday and at the same time be different days? Would the definition of “day” be different based on whether you are talking about “day of the week” vs “universal day”?
Yup.
I’m just thinking about things like scheduling dentist appointments at my local dentist. I’d think it would be less confusing for ordinary local interactions like that if we could say “next Wednesday at 20:00” rather than having to keep track of the fact that depending what period of the day it is (relative to landmarks like “dinner time” or “midmorning”) it may be a different day of the week.
And it’s not like there aren’t awkward mismatches beteen days of the week and days of the month now. Months don’t always start on the first day of the week, for instance. (Hell. We don’t even agree on what the first day of the week is.) “Weeks” are an artifact of lunar calendars. (And, to be fair, so are months.)
(And while we’re on the topic of months, we should have 13 of 'em. 12 of length 30 each and one at the end of 5 days or on leap years 6 days. And they should be called “first month”, “second month”, “third month”, etc. None of this “for weird historical reasons, October is the 10th month, even though the prefix ‘oct’ would seem to indicate it should be the 8th” bs. Lol.)
Well Devops isn’t a role. It’s an approach in which bridges development and operations and integrating it in the team. It isn’t sticking a cloud engineer (cloud biased sysadmin) in the team. It’s about collaboration and delegating and supporting.
Cloud engineer is unfortunately what many orgs think devops is.
What about the cloud engineer job do you dislike the most? I’ve been in the field for 7-8 years now and still find a lot of joy. Granted, the most frustrating parts of my job is lack of influence I have over the decisions that get made, but I moved to a team lead position to at least have a little say.
I hate everything about cloud engineer especially when tweaking & deploying, after that your boss blame you because the company got higher bill just because the apps have tons hidden micro service & peaked the server like crazy & your coworkers that made the apps got praise because your boss & project manager didn’t know anything about IT
IT workers desperately need to unionize. There is so much bullshit that happens, folks are expected to do three different roles at once, have multiple technical stacks they are experts in, and work extra hours + be on call after hours or on weekends.
100%. A full on IT Workers Union would immediately become one of the most powerful weapons in fighting the oppression of the capitalist class. An IT strike could be effective enough that a general strike wouldn’t be necessary
It can be. I often find it “bursty.” I’ve had months at a time when I had stand-ups and then “do whatever you want” for the rest of the day. I generally did do useful work, but there were plently of days when I was just chilling out.
Ive also had months where I ran from fire to fire while on fire, spreading even more fire. Also, there was fire.
It juat depends. If some org treats you as disposable, pays like shit and lights your hair on fire as you walk in, y’all should walk back out. The next org will probally treat you better, because there are good orgs out there. Even the good places get busy for a bit though. Just make sure that busy comes with money and that it ends at some point.
This is how I would describe my experience. Sometimes it’s crunch time and most of the time it’s fuck around time. After crunch time I always throw a tantrum about how if we only bothered with planning we could largely avoid it.
If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let’s hope WASI is up to the task!
I think WASM/WASI still has a ways to go before that’s realistic, but I’d keep an eye on them for the future.
But that logic makes no sense, tbf, given how container was way back in BSD. I like how it is a balanced choice between an ephemeral environment and virtualization.
If we are talking about how NodeJS is the biggest pain in the ass to maintain for distros, and how they’ve forcibly tied V8 into the repository, that I’d agree gladly.
As a friendly trash-dev, I’d recommend never to open the deps folder, I’d bet that most of you folks will have a stroke.
Oh yes, that I agree on. And I’ve been following WASM, although not with great enthusiasm. Guile has Hoots integration, and I believe there was a Scheme game jam recently with most projects using this.
I think the very long-term goal is for it to be the universal virtual machine, for all front-ends and all back-ends, and for all popular programming languages. And given that its status on the browser has already been secured, I don’t think it’s impossible for the long-term vision to be reached, eventually.
From a practical standpoint I’m really not qualified recommend one over the other, but the licensing is different. Podman also seems to be more “open source-y,” but I’m going on vibes here; perhaps someone more knowledgeable can elucidate.
I would suggest that if someone is using neither, perhaps consider podman as open source. However, I too would need a reason to move. I mainly use synology for images, so its their container manager, rather than docker but my understanding is its docker under the hood.
From what I heard, podman doesn’t require root but that’s about it. On the other side, it’s a redhat thing and it’s not as popular which means less documented and less containers
Supposed to be an easy, if not a drop in replacement afaik, it’s under a permissive licence (Apache 2.0), beyond that it’s authored by RedHat I can’t tell you much else, it’s something I’ve been considering moving to personally (and work, pretty much for licencing and the few of us that want to use more open tech stacks) I just haven’t had a chance to work with it.
Supposedly able to pull docker images and work with docker-compose, just not swarm.
I honestly and truly don’t want to spend time relearning another system like this, especially one without decades of documentation and support available.
Bro you've already been told on at least one other programmer humor community to stop shilling your mediocre Long Dark rip-off here. Take this to game dev or indie studio / creator communities
programmerhumor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.