Europe goes into daylight saving time despite controversy
-
Summary
Most European countries moved clocks forward one hour on Sunday, marking the start of daylight saving time (DST), a practice increasingly criticized.
Originally introduced during World War I to conserve energy, DST returned during the 1970s oil crisis and now shifts Central European Time to Central European Summer Time.
Despite a 2018 EU consultation where 84% of nearly 4 million respondents supported abolishing DST, implementation stalled due to member state disagreement.
Poland, currently holding the EU presidency, plans informal consultations to revisit the issue amid broader geopolitical priorities.
The simple fact is that on the Monday after DST starts, more people have heart attacks and strokes.
Meaning that not going away from it means people will continue to die from it.
-
If you like more light in the evening, go to bed late and wake up late. If you like light in the morning, go to bed early and wake up early.
Other way around. If you want a lighter evening, your day has to slide earlier so when you sleep is closer to sunset.
-
I’m okay with that plan, although I’m curious why you find it so important.
In any case that’s a problem with the layout of time zones not with DST.
For most of the past 110 years or so since DST was implemented, for 3/4 of the year, we have had solar noon occurring at 13:00 in the center of each time zone. You're already living with it most of the time. We've established school schedules, work schedules, industrial schedules, laws (such as curfews, noise ordinances, parking enforcement) and all sorts of infrastructure on the idea that for 3/4 of the year, there will be one more hour of daylight after 12:00pm than there is before 12:00 pm.
Noise ordinances, for example, were established on the expectation that people should have the opportunity for sleep, and workers should have the opportunity to provide their services. They don't get to work until the protected quiet period ends.
Either approach we take, we are going to upend a wide variety of laws, rules, practices, and customs that have been established over the past century. Adopting legacy standard time is going to impact events over 3/4 of the year; adopting permanent DST is going to impact events over 1/4 of the year.
We should select the system that minimizes disruption. That system is DST.
-
In North America DST is used from second Sunday of March until first Sunday of November.
This means there are 239 days in DST, and 126 days out of DST in 2025. Close to 2 to 1 ratio.
I know it's different with CEST and CET, and it sucks even more donkeyballs there, when the sun sets around 4PM (instead of 5) regardless.
DST should really be the standard in most places. You want more sunlight in the afternoon, not in the morning.
I prefer more sunlight in the morning. It's better for your circadian rhythm and it is easier to wake up when it's bright outside.
-
Yes but
It makes programming hard
Nobody stops programmers from converting everything into UTC when data and queries go in and back to local time when data comes out.
In fact I worked in a number of systems used across quite a number of time zones (mainly EMEA, but sometimes including all of the US) in Finance and that's exactly how we did it.
Users could work with their local time and meanwhile the system was always internally consistent because at the data level it used a single standard timezone (which has no such thing as daylight savings) for the whole World.
Handling Timezones in systems with a central master datastore for the whole World is a solved problem, it's just that most programmers don't actually work in such systems during their careers so aren't used to it.
-
Nobody stops programmers from converting everything into UTC when data and queries go in and back to local time when data comes out.
In fact I worked in a number of systems used across quite a number of time zones (mainly EMEA, but sometimes including all of the US) in Finance and that's exactly how we did it.
Users could work with their local time and meanwhile the system was always internally consistent because at the data level it used a single standard timezone (which has no such thing as daylight savings) for the whole World.
Handling Timezones in systems with a central master datastore for the whole World is a solved problem, it's just that most programmers don't actually work in such systems during their careers so aren't used to it.
It's like you didn't think I had real life scenarios that didn't fit into this fix.
What happens when the interfaced system provides a date without timezone information? What happens when they provide multiple timezones? What happens when they have more than one site location, and they just send you a 12-hour time and date?
You can always point to the customer - say "hey, we need better data." But what happens when you have 4000 customers scattered all over the world?
Or another scenario - you are doing optical character recognition, and the document always has a date/time on it. The date and time is usually printed, but sometimes it's handwritten. Maybe part of the process is to verify that date matches with a date in a legacy system. The date in the legacy system is local to your business, but there is no information on what the datetime on the document is.
I've run into so many problems with time in my career that I'm fairly certain it's created more work than any other problem.
-
Mid-day should be the middle of the day.
Mid-night should be the middle of the night.If you like more light in the evening, go to bed late and wake up late. If you like light in the morning, go to bed early and wake up early.
Stop fucking with the clocks and making nonsensible decisions
Na, we should get rid of that idea completely. If everyone used one time like UTC (other time zones are available) and just align your working hours etc to your location.
Then 14:00 is 14:00 everywhere, just that some are asleep then, others are awake!
-
It's like you didn't think I had real life scenarios that didn't fit into this fix.
What happens when the interfaced system provides a date without timezone information? What happens when they provide multiple timezones? What happens when they have more than one site location, and they just send you a 12-hour time and date?
You can always point to the customer - say "hey, we need better data." But what happens when you have 4000 customers scattered all over the world?
Or another scenario - you are doing optical character recognition, and the document always has a date/time on it. The date and time is usually printed, but sometimes it's handwritten. Maybe part of the process is to verify that date matches with a date in a legacy system. The date in the legacy system is local to your business, but there is no information on what the datetime on the document is.
I've run into so many problems with time in my career that I'm fairly certain it's created more work than any other problem.
When the date timezone is not specified the interface just picks up the local time of the user. Even web stuff will send you this info so even there is perfectly doable.
I'm talking about systems where we design both the interface and the backend.
If the user wants a different behaviour it's up to them to specify it and the interface is designed so that they can do it it - if they don't it's their problem, not the system's: this is hardly the only situation were the software can't just guess information that's not provided to them (random example, when a full name is provided in a single line: has it been provided family name first and then surname or the other way around - this is also an international problem by the way since in most of Asia the natural order tends to be family name first: the most common solution for this is to just break it into two fields, explicitly one for surname and family name, but that introduces the problem of which middle names are part of the surname and which of the family name for people with more than 2 names).
Generally the approach in systems design for balancing the need for complete and consistent information of a software system operating in a certain environment (such as across timezones and having to compare data between time zones) with users, being human, naturally only providing part of the information and not context (mentally they just assume those things which for them "are always the same" and generally don't even think about them) is to provide good defaults and if that context information is important for your system, designing the UI to have a "validate this" step which makes it very obvious the default value that has been filled for that information or some other mechanism (it really depends on the business process that the user is following) and lets the user change it (for when they do in fact want something else), along with the means for the user to pull out that data and correct it later because somebody at some point will invariably make a mistake in entering data and have to fix it.
All this is a foundational element of software design - humans will always go around carrying tons of assumptions in their minds about a ton of things and don't want to "waste time" always filling in the form the value for those assumptions, so as a system designer you have to find a balance between not wasting the time (and patience) of lots of users because you're forcing them to have to enter info that's redundant 99.99% of the time, and data consistency - and you do that by designing appropriate user flows and user interfaces, which taking in account that people will always make mistakes (so you design your system to reduce the chances of human error AND give them a process for later correcting the info info they entered).
Granted, proper design of multi-tiered systems (which include a UX/UI) to balance user needs and the almost laughably bad level of data "integrity", completness and consistency in the minds and communication of human users, with system needs, isn't exactly a common skill amongst software developers: I've seen plenty of junior devs and even mid-level devs expressing the very same frustrations as you about lots of things (not just dates and times) and blaming the users - blaming lusers is almost a stereotipical thing for programmers at a certain level of seniority - and then the whole thing boils down to crap systems design (often UI, but often also things like not have the appropriate steps in user flows to make sure unusual cases - such as users entering times in a timezone other than their local one - are spotted and validated/adjusted) and/or their own selfisheness that life should be harder for the many in order for them - the few - having an easier life.
Ultimatelly, the (IMHO) error of your point of view is that you seem to be forgetting that we programmers do our work for our users, not for ourselves - it's up to us to design our software to be used by humans within the environment they live in, not for everybody else to change their lives to make our job easier. This too is a foundational element of software design.
It's up to programmers to adapt to the conventions of most people in the World, not the other way around.
-
Yup, the time without DST is fine and they introduced DST that is an issue
-
Summary
Most European countries moved clocks forward one hour on Sunday, marking the start of daylight saving time (DST), a practice increasingly criticized.
Originally introduced during World War I to conserve energy, DST returned during the 1970s oil crisis and now shifts Central European Time to Central European Summer Time.
Despite a 2018 EU consultation where 84% of nearly 4 million respondents supported abolishing DST, implementation stalled due to member state disagreement.
Poland, currently holding the EU presidency, plans informal consultations to revisit the issue amid broader geopolitical priorities.
I would have never known if it wasn't because a coworker told me or because of articles like these. My cat wakes me up at 7- 7:30 and he did that this morning too, so I was very surprised that I slept only 7 hours instead of 8 (before I knew). But the funnits part is that my cat followed DST haha
-
In North America DST is used from second Sunday of March until first Sunday of November.
This means there are 239 days in DST, and 126 days out of DST in 2025. Close to 2 to 1 ratio.
I know it's different with CEST and CET, and it sucks even more donkeyballs there, when the sun sets around 4PM (instead of 5) regardless.
DST should really be the standard in most places. You want more sunlight in the afternoon, not in the morning.
Of course the US does DST several weeks later than the rest of the world
-
In North America DST is used from second Sunday of March until first Sunday of November.
This means there are 239 days in DST, and 126 days out of DST in 2025. Close to 2 to 1 ratio.
I know it's different with CEST and CET, and it sucks even more donkeyballs there, when the sun sets around 4PM (instead of 5) regardless.
DST should really be the standard in most places. You want more sunlight in the afternoon, not in the morning.
I'd definitely prefer more sunlight in the morning. It's 6:45am right now and the sun hasn't even risen yet and won't start for another half hour.
Meanwhile, more sunlight later in the day is often gone to waste anyway, between work/dinner/etc.
But honestly, I would take either as long as it stops changing.
-
Summary
Most European countries moved clocks forward one hour on Sunday, marking the start of daylight saving time (DST), a practice increasingly criticized.
Originally introduced during World War I to conserve energy, DST returned during the 1970s oil crisis and now shifts Central European Time to Central European Summer Time.
Despite a 2018 EU consultation where 84% of nearly 4 million respondents supported abolishing DST, implementation stalled due to member state disagreement.
Poland, currently holding the EU presidency, plans informal consultations to revisit the issue amid broader geopolitical priorities.
Wasn't DST invented in America? How did it even get adooted by the EU?
I'm also seeing that it was formerly used in Russia, India, South America, and some parts of Africa, and it is still used in 4/5ths of Canada and 1/3 of Australia.
-
Mid-day should be the middle of the day.
Mid-night should be the middle of the night.If you like more light in the evening, go to bed late and wake up late. If you like light in the morning, go to bed early and wake up early.
Stop fucking with the clocks and making nonsensible decisions
my problem with that is thats not really up to me, if i have to be up for work or down for work in a given time.
-
I would have never known if it wasn't because a coworker told me or because of articles like these. My cat wakes me up at 7- 7:30 and he did that this morning too, so I was very surprised that I slept only 7 hours instead of 8 (before I knew). But the funnits part is that my cat followed DST haha
Your cat must be in on the conspiracy. Perhaps even part of the deep state.
-
Wasn't DST invented in America? How did it even get adooted by the EU?
I'm also seeing that it was formerly used in Russia, India, South America, and some parts of Africa, and it is still used in 4/5ths of Canada and 1/3 of Australia.
New Zealand entomologist George Hudson first proposed modern DST.
Easy to google, bud. Also, the concept is ancient.
-
New Zealand entomologist George Hudson first proposed modern DST.
Easy to google, bud. Also, the concept is ancient.
That guy was in 1895, which is a hundred years after Ben Franklin suggested it, but neither of them were responsible because it wasn't adopted until the early 20th century in Canada, Germany, Austria, and the USA.
-
Summary
Most European countries moved clocks forward one hour on Sunday, marking the start of daylight saving time (DST), a practice increasingly criticized.
Originally introduced during World War I to conserve energy, DST returned during the 1970s oil crisis and now shifts Central European Time to Central European Summer Time.
Despite a 2018 EU consultation where 84% of nearly 4 million respondents supported abolishing DST, implementation stalled due to member state disagreement.
Poland, currently holding the EU presidency, plans informal consultations to revisit the issue amid broader geopolitical priorities.
The thing I don't get is why it happens in the summer rather than the winter.
In the UK it gets dark at about 4pm in winter. We basically get no leisure time during daylight but we do get a bit of light during getting ready for work time when we don't really need it.
-
Morons, people who didn’t read it fully, and people who want to encourage discourse.
-
When the date timezone is not specified the interface just picks up the local time of the user. Even web stuff will send you this info so even there is perfectly doable.
I'm talking about systems where we design both the interface and the backend.
If the user wants a different behaviour it's up to them to specify it and the interface is designed so that they can do it it - if they don't it's their problem, not the system's: this is hardly the only situation were the software can't just guess information that's not provided to them (random example, when a full name is provided in a single line: has it been provided family name first and then surname or the other way around - this is also an international problem by the way since in most of Asia the natural order tends to be family name first: the most common solution for this is to just break it into two fields, explicitly one for surname and family name, but that introduces the problem of which middle names are part of the surname and which of the family name for people with more than 2 names).
Generally the approach in systems design for balancing the need for complete and consistent information of a software system operating in a certain environment (such as across timezones and having to compare data between time zones) with users, being human, naturally only providing part of the information and not context (mentally they just assume those things which for them "are always the same" and generally don't even think about them) is to provide good defaults and if that context information is important for your system, designing the UI to have a "validate this" step which makes it very obvious the default value that has been filled for that information or some other mechanism (it really depends on the business process that the user is following) and lets the user change it (for when they do in fact want something else), along with the means for the user to pull out that data and correct it later because somebody at some point will invariably make a mistake in entering data and have to fix it.
All this is a foundational element of software design - humans will always go around carrying tons of assumptions in their minds about a ton of things and don't want to "waste time" always filling in the form the value for those assumptions, so as a system designer you have to find a balance between not wasting the time (and patience) of lots of users because you're forcing them to have to enter info that's redundant 99.99% of the time, and data consistency - and you do that by designing appropriate user flows and user interfaces, which taking in account that people will always make mistakes (so you design your system to reduce the chances of human error AND give them a process for later correcting the info info they entered).
Granted, proper design of multi-tiered systems (which include a UX/UI) to balance user needs and the almost laughably bad level of data "integrity", completness and consistency in the minds and communication of human users, with system needs, isn't exactly a common skill amongst software developers: I've seen plenty of junior devs and even mid-level devs expressing the very same frustrations as you about lots of things (not just dates and times) and blaming the users - blaming lusers is almost a stereotipical thing for programmers at a certain level of seniority - and then the whole thing boils down to crap systems design (often UI, but often also things like not have the appropriate steps in user flows to make sure unusual cases - such as users entering times in a timezone other than their local one - are spotted and validated/adjusted) and/or their own selfisheness that life should be harder for the many in order for them - the few - having an easier life.
Ultimatelly, the (IMHO) error of your point of view is that you seem to be forgetting that we programmers do our work for our users, not for ourselves - it's up to us to design our software to be used by humans within the environment they live in, not for everybody else to change their lives to make our job easier. This too is a foundational element of software design.
It's up to programmers to adapt to the conventions of most people in the World, not the other way around.
By "interface" I meant the data interface between systems. Not a User Interface.
Additionally, it's been my experience that I rarely get to design the full stack - we inevitably have to handled data exchange and legacy systems. Those legacy systems are a type of "user" in this instance that we have to program for. We can take a 13:30 string, and store it in UTC, but without location or time zone being provided through that (which the message queue that we pull from doesn't have), it doesn't do us anything.
The solution for these type of problems usually involve find another source of data and mapping the time that way. This inevitably ends up being far more work for us because of the security, traceability, auditing, etc.
