I'd actually like to list the worst things (IMO) to happen to the software industry.
(1) Marketing of computers at boys resulting in a generation of girls being excluded. (2) Software patents suffocating innovators. (3) DMCA & international equivalents (4) Daylight savings time. (5) A generation of programmers being taught that anything other than "OOP best practice" was heresy
I'm sure there are plenty I'm missing.
Does one particular programming environment deserve to be listed with that stuff? Personally I think it's a pretty ludicrous suggestion.
It's always annoys me whenever programmers complain about time zones and daylight savings time, because of the difficulty and inconvenience handling them in software. It's getting things backwards. Software should model the (human) world* ; the human world shouldn't be changed to model what's most convenient for software.
* That doesn't mean you can't have a simpler model that you translate to/from.
> Software should model the (human) world* ; the human world shouldn't be changed to model what's most convenient for software.
Agreed, but my point is that daylight savings time is a huge human-world complexity that brings a marginal boost to some sectors. There are a ton of negative effects and I question whether there's a net benefit, even before all the software complexity needed to support it.
Oh man, "OOP as gospel"... If there's one thing that I like about Node.js, it's that it made me actually think about when I should take an object oriented approach vs a functional approach.
Dealing with time-zones and daylight savings time (which countries have it and which don't) can be a very challenge and messy problem that is really easy to get wrong.
Most do, but the problem is less about the library and more about understanding how to use it.
For example, if you want an event to happen in 12 hours, and it happens to be 9pm the day before daylight savings time, do you schedule it using the timezone-aware API (so it happens at 9am, which is actually 13 hours away) or 8am (which is 12 hours, but non intuitive)? What about the event that's supposed to happen every 12 hours in perpetuity?
What happens when the user/device is mobile, and crossing timezones? Which times do you use?
What happens when you're scheduling something far in advance, and then the timezone definition itself changes (as happens a few times a year) between the time you scheduled the event, and the time something actually is supposed to happen? Does the event adjust for the new definition or follow original time?
Luckily for many problem domains, the details around this don't matter too much, but this is just the tip of the iceberg with timezone challenges.
E.g. a rather trivial example of displaying a hourly graph/table of some measurement, including comparison with yesterday (because there are daily patterns of fluctuation).
DST means that some of days have 23 hours and some days have 25 hours. The libraries will help you make the relevant calculations, but now you have to make a decision wether the comparison that you make with "yesterday equivalent" of today's 11:00 is yesterday's 11:00 (23 hours ago) or yesterday's 10:00 (24 hours ago).
For another example, accounting of hours worked - you may have a person that has worked 25 hours in a single day, such events break some systems.
DST adds complexity to the already ugly mess timezones are. Timezones are literally driven by real-world politics, and they can be as messy as only humans can invent.
As well as adding to the already-confusing mess of timezones and date calculations, daylight savings can change frequently, and sometimes at very short notice.
This year, Azerbaijan decided to cancel DST, and agreed the cancellation just 10 days before the scheduled clock change [1].
Egypt cancelled DST with even less notice - just 3 days! [2]
It has to be accounted for in time and date calculations and that poses a new set of challenges.
It is also just one of many geographical, cultural, and temporal challenges that need to be addressed by any business system relying on accurate international dates and timing.
Time and scheduling are a bit tricky, to say the least. It would help if there were some reasonable assumptions that you can make - for example, a day containing 24 hours. DST makes such assumptions not true.
Wow! You haven't run into DST issues in software yet?! How I envy you! If you work in the industry, you have a lot of fun unintuitive but sort of neat bugs to look forward to!
I'd actually like to list the worst things (IMO) to happen to the software industry.
(1) Marketing of computers at boys resulting in a generation of girls being excluded. (2) Software patents suffocating innovators. (3) DMCA & international equivalents (4) Daylight savings time. (5) A generation of programmers being taught that anything other than "OOP best practice" was heresy
I'm sure there are plenty I'm missing.
Does one particular programming environment deserve to be listed with that stuff? Personally I think it's a pretty ludicrous suggestion.