I wonder - have any of you who run large projects which are sensitive to time changes ever have to deal with DST? I ran a MMORPG, which had specific events at certain times of the day, on certain days of the week. Now imagine:
North America observes DST two weeks before Europe. DST ends for Australia two weeks before North America (time goes the other way). China does not observe DST. I won't even bother to get into the other countries.
Even disregarding the other issues that DST created (and trust me, there were lots), just syncing up players for events was a giant hassle. Yes, people should theoretically research and know how their time works, but expecting users to sync your events to their time without missing one or two is naive ignorance. Even with mitigations, my staff and I basically spent every DST start/end dealing with a plethora of IRs to the degree of, "why did you change the time?"
I would not miss DST at all.
(We did standardized time quite early on, and did announce in server-time)
One large set of projects is world-wide Ham Radio contests. This gets rid of the time zone problem and the Daylight Time Savings problem, or the British Double Summer War Time problem. And it isn't just the contests--pretty much all of radio timekeeping is done in UTC (formerly called GMT), affectionately known as Zulu, with a 'Z'.
I participated in one expedition to Vanuatu with five other guys from our radio club (the Prairie Dx Group) in which we flew from Chicago. 28 hours of travel to get there. Lost one particular Thursday in the process. We were keeping a web site updated with our results in real time, and had to keep in touch with the webmaster. The event was run on Z time, and the daylight obviously was on local time. So we were tracking three different time zones in an event that ran around the clock, and pretty much had no intuitive sense of what time it was.
But in worldwide radio communication, it is often important to know what the sunrise and sunset times are in the places you hope to communicate with. Many of my friends who are very good at this know this for important locations around the globe for various seasons.
One thing you can do to get used to UTC is to set your wrist watch or the office clock to UTC. You will shortly adjust, or miss dinner.
And as a life-long ham, when I write times, I use four digits: "I am on the 1800 train coming home." Some folks say "wtf", and others you can catch them counting on their fingers.
Eve Online solved that by having an in-game clock which is always set to UTC, then all in-game events are announced in Eve time (sometimes with GMT / PST / etc in brackets); I've not seen anyone complain about the time zones there (though I only hang out in player channels, I don't see the official support tracker :P)
That said, you don't need GPS to get a UTC clock. EVE Online for example determines the clock drift on connection to the servers by bouncing packets around.
> Swatch Internet Time (or beat time) is a decimal time concept introduced in 1998 and marketed by the Swatch corporation as an alternative, decimal measure of time. One of the goals was to simplify the way people in different time zones communicate about time, mostly by eliminating time zones altogether.
> Instead of hours and minutes, the mean solar day is divided up into 1000 parts called ".beats". Each .beat lasts 1 minute and 26.4 seconds. Times are notated as a 3-digit number out of 1000 after midnight. So, @248 would indicate a time 248 .beats after midnight representing 248/1000 of a day, just over 5 hours and 57 minutes.
> There are no time zones in Internet Time; instead, the new time scale of Biel Meantime (BMT) is used, based on Swatch's headquarters in Biel, Switzerland and equivalent to Central European Time, West Africa Time, and UTC+1. Unlike civil time in most European countries, Internet Time does not observe daylight saving time.
Yeah, I know what you mean. I run a large gaming website. For tournaments, two or more players have to agree on a time to meet and play.
A dialog goes something like this: Player A: I live in X time zone and 3pm works for me. Player B: OK, I'm in EST, let me see what time that is for me. ... OK, that works!
And then Player A and Player B miss each other, because Player B wasn't aware that his current time zone was EDT, not EST.
Even if both players convert to UTC first it doesn't work, because EST -> UTC and EDT -> UTC yield different times. And it's difficult to help them out with site-mandated time tools, because players like to coordinate over IRC, Twitter, GChat, ...
I'm sure there's a good way to fix this problem, I just feel like I shouldn't have to.
EDIT: I just saw the Eve online comment. Unfortunately that doesn't work quite as well for us, as the game isn't a program that's always running on the player's computers. It's more in the spirit of trying to coordinate chess matches.
Seems like this could be solved on your end with code. Just add a sprinkle of Javascript to detect what timezone they're in and either show them the UCT time or maybe set up a button saying something like "Suggest Time" where the player who clicks it sees the time for their own timezone but the UCT time is sent across so that the other player sees it converted to their own time.
This is a _community_, not a web app. Maybe the two words mean the same thing to people nowadays, but it didn't back in ~1999, when this community was formed--5 years before the website was formed. It's not the case that the website is the central hub for everything. As I said, players sometimes prefer coordinating over IRC or other mediums. And in some cases, there isn't one central place to play matches.
You can certainly mitigate the problem by encouraging people to use a web app to coordinate. Maybe there is an incentive structure that would help drive adoption. But whether or not people use the web app or not, they are still apart of the community and we have to serve them. I don't necessarily decide who is in and who is out.
Anyway, the point of my post wasn't to complain that there aren't workarounds. There are. I just think we as a society _shouldn't have to workaround DST_, and I wanted to add my lend my (largely insignificant) story to the cause.
>Even with mitigations, my staff and I basically spent every DST start/end dealing with a plethora of IRs to the degree of, "why did you change the time?"
For us the mayhem used to last for weeks because DST changes in different countries at different times. However, the biggest challenge was always to convey to many programmers that despite a date being in different timezones, the UTC timestamp is always the same and that timezone merely changes the interpretation of a UTC timestamp. Than there was the nuisance of different machines running in different timezone and some automatically generated cron jobs all going haywire. And then, any scripts you write to fix the issue have to wait for 6 months before they can be battle tested. It took us a good 3 DST changes to finally solve the problem and still it is quite an unpleasant hack.
No, I would not miss DST either. After all it has been more than a century since light bulb liberated us from relying on the Sun as the sole source of light.
I never get how MMORPGs could consistently get this so wrong time & time again. It always boggles my mind that the Devs could miss putting a simple locale aware date/time picker/presenter into the game and on the website.
Computers can deal with this. Computers have been dealing with this for decades. Your computer knows which locale you are in.
Use the bloody computer.
It's almost like the joke that hardware guys can't program, gaming devs can't make simple forms. Or menus for that matter.
Totally and fundamentally wrong. Better use bloody logic.
Server-wide events are meant to start/end in sync. This isn't a plain stupid web form. What if some smart arse switches time zone to have an event earlier and then end later?
Have the events occur at specific absolute times but show the time in the player's time zone. If they switch zones they see different times, not change the behaviour of the game.
It's not complicated, every language has simple code to change a local time to UTC and back again and it's built in to every computer. It's a solved problem.
Most devs who have ever had to deal with dates know to send any user-input to the server with the TZ information attached, to then always store that time in UTC and then translate that for the user, either client-side if you're sending raw data, or asking for a timezone setting and transforming it server-side (if you're sending HTML for example. Browsers, alas, do not tell the server what timezone the request is coming from, which is why all forums ask you for your tz so they can show the correct post time, relative to you).
Apart from, seemingly, game devs.
How on earth do you think the world has been operating without the basic functionality of being able to talk about an explicit, locale neutral time? To translate a TZ specific date/time to another TZ specific date/time? Banking would be buggered.
I won't even bother to get into the other countries.
I support a single use device application (running on Palm E2s!) that requires constant fiddling to keep up with DST changes around the globe. In the past, some countries have changed their DST observance mere weeks before it was supposed to happen.
I work as part of a mostly American dev team, but out of Sydney. We vary between having team meetings at my midnight, which includes the US East, but doesn't include the US West, or 8-9am, which can include the US West but not the east. The former becomes 2am with Aus moving one way and the US East moving the other, at which point I stop having any real contact with the US East.
Yes, but I use the zonetime database that's built into many OSes to handle that. We make people tell us their timezone, but translate it spatially, not into zones. Points in space are sufficient to do actual UTC-to-local translations while "zones" are not. This is what's happening when you see "America/New_York" as your "time zone".
Ran into DST problem when I had to build a Gantt chart in flash, project scope just so happen cross the time change while development. I ended up solving the bug but it wasn't fun on bit.
This is one this I'm thankful for in the .Net framework. Give it any datetime in UTC, then give it a time zone and it spits out a local time. There is zero work to do.
While I admit that using a framework instead of your own solution is a good solution, please note that that's not "zero work", it just passes the buck to the client. The framework's knowledge of the timezones still has to be kept up to date. For example, Israel used to have ad-hoc DST times changing each year and "...the unpredictability of IDT in Israel became frustrating enough that Microsoft Windows stopped trying to track changes and just made Israeli time be Greenwich Mean Time plus two hours (GMT+2) (and disabled the daylight saving option). This has led to various ad hoc solutions to the problem in Windows systems and other Microsoft software (e.g. Outlook calendar entries are often off by an hour when shared, due to the lack of IDT support)." [1]
You realize that the tzdb files this functionality depends on has several updates each year that are probably never being installed on 90% of computers?
I wish we would go one step further and just stick to UTC as well. That way when we try to set up a video conference at 0900 we don't have to translate between time zones. We can just ask if 0900 works, and everyone would know what time that is.
There's no reason 1200 should be midday. If we changed this today the next generation would never stop to think about how "weird it is that it's dark at 1200" where they live.
Time zones tend to come into effect in two situations: when you need to communicate across them, and when you need to travel between them. In the former situation, I agree that having one universal time would simplify things. Also agreed that as long as you tend to stay in one area, it wouldn't be a big deal to get used to dawn at 17:00 or whatever. What I think would be tricky is if you did a lot of traveling. With time zones, you can simply change your watch/phone to local time, then work based on that. With universal time, you would need to either constantly work out what time morning/lunchtime/business hours/etc. are in this new place, or you would have to change your watch/phone to some fictional time to simulate the times you're used to. Either one seems significantly trickier.
Of course, nothing stops people from using UTC only for the situation where it's really useful: long-distance coordination. (And as mentioned in other comments, that's often done already.)
The two situations where time zones are relevant is a very good observation, but I still think we should optimize for the more common case, which is communicating across timezones.
This wouldn't solve much of the communicating across timezones problem - although you may no longer have to look up the canonical time, you instead have to look up the solar time or local time convention (are they sleeping? are they at work?)
So, it's better to keep the second problem ('what time is morning?') more accessible, since you need that in both cases.
The current use of timezones seems primarily designed to ease adjustment for those traveling between them. Work starts at 9 AM in region-X, you move to region-Y, adjust your time and work starts at the "same" time.
Today I think however there are a lot more cases of cross-timezone communications, and a lot of people are telecommuting to work and various events. It may be time to move on and adjust to better support distance communication and telecommuting.
Bad idea. You would still have different people in different places experiencing different parts of their day, even if you put them all on UTC or had no clocks at all. You still have to figure out what they are doing before you call and figure out whether it is too late to call, or too early, or they ought to still be in the office, etc., one way or another.
So what do you optimize for? For the ability to live your life anywhere you go with the same basic assumptions you and everyone else grew up with about when people wake up, are at work, eat, etc., or do you optimize for the convenience of the occasional synchronization of multi-locale events?
If your wake up, jet lagged, look at your watch, and it says 1800, are you too late for breakfast? Are you too early to call someone you came to visit? The fact that you didn't have to reset your watch for the local time means you know exactly what's going on back in the place you left. Great. Too bad you don't have any idea what's going on where you actually are. You can save yourself the trouble of setting your watch, and be confused about when to do what all day long, or you can set your watch once and be completely oriented to your new locale by lifelong instinct.
Given the choice of having to do a clock calculation to synchronize occasional events versus having to get used to a different daily life pattern everywhere you live, visit, or even call, I'll take the former.
Use UTC for synchronizing events. Use local time for living life.
> You still have to figure out what they are doing before you call
To me, something like “in Japan, people usually start their workday at 2100 (or at 2000 in winter)” seems less complex than “in Japan, people usually start their workday at 8:00, which is 2100 (or 2000 in winter)”.
> If your wake up, jet lagged, look at your watch, and it says 1800, are you too late for breakfast?
If you wake up, jet lagged, look at your watch, and it says 18:00—which place this time refers to?
I think having global time would be simpler (though it's impossible anyway due to politics and people's inertia).
...seems less complex than “in Japan, people usually start their workday at 8:00, which is 2100 (or 2000 in winter)”.
That's not how calls to Japan currently work, and I make plenty of them. You check the world clocks on your phone and see that it's 6:00am in Tokyo. You know what 6:00am means: it means what it has always meant for you and everyone else, everywhere in the world, since you and they were born. You decide to give them a call later. The end.
Life in different places on the globe is not synchronized just because you assign everyone the same universal clock time. You can either look up the local time in Japan, and know immediately what that means, or you can look up your clock time here, know immediately the clock time in Japan, and still not know what you need to figure out: what's going on right now in Japan. You still have to look that up somehow, but the answer won't be a simple local time that everyone understands intuitively, because local time maps differently to the daily cycle of life in every locale.
I think having global time would be simpler
Well, everyone's watches would say the same thing. That's the good news. The bad news is that they would all mean something different.
though it's impossible anyway due to politics and people's inertia
The inertia of things that work well in practice is a valuable shield against seemed-like-a-good-idea-at-the-time theories. I find UTC very useful for viewing astronomical events. When I need it, it's just another clock. It doesn't mean it needs to replace the far more useful local time for daily life.
You are misunderstanding how it would work. People would still be awake when it's light out and asleep when it's dark.
Instead of everywhere starting their workday at 9am UTC like you're imagining, London would start their workday at 9am UTC, New York would start their workday at 4am UTC, Los Angeles would start their workday at 1am UTC.
Actually, that's exactly how I know it would work. I'm pointing out the information your going to loose without having timezones because people are still going to get up and go to sleep basically following a solar day. Are people in Paris awake at 9:00 or asleep? Are people in LA working or not? Without a table, say a table that says what time of day it is in particular zones, 9:00 tells you nothing.
Nit: If we eradicate timezones, lets also get rid of this am/pm nonsense. New York wouldn't start at 1am, they would start at 1h00 (or 01:00, or 01h00, or however you want to notate it).
Not really. Two places with the same timezone may have completely different day and night schedules. The northen hemisphere is flooded with sunlight during Northen summer, while the souther hemisphere gets very little sunlight during this time.
Extend the issue out, when I want to call my mother around the world, how do I know she's not ill today, took the day off and went to bed early?
You're creating an issue by extending something to absurdity.
Specifics like that aren't going to be communicated with any system, but removing timezones removes the general idea that is communicated with 9am or 7pm.
Siesta is an essential part of daily schedule in many places. “Took the day off”, “ill”, “went to bed early” are obviously extraordinary circumstances.
Because instead of just remembering that Spanish people siesta from 1200-1400 local time, you might as well translate it to UTC and make it even more complicated to remember?
It is possible that it appears complicated because it is not common to use UTC. But let's try to imagine the scenario further...
So Spanish people typically siesta between 1100 to 1300 UTC. Imagine, my home country is UK. I work between 0900 to 1800 UTC. Imagine I travel to US and need to call my Spanish friend. In the US, when I reach the east-coast I realize that I work between 0200 to 1100 UTC. At once I can deduce when to call my Spanish friend; it is before I leave my work at 1100 UTC.
Frankly, even I had not thought through completely the UTC based scenario, until now. I am now even more convinced that it's the most convenient way forward.
When does your Argentine friend siesta? When does your Japanese friend get off work? What's a good time to phone your friend in Australia? You've just landed in Tokyo--when should you be getting to sleep? You still have to do time zone calculations, but you don't have the time zones anymore.
The place where this scheme falls down is that for many people the date (and day!) will change some time during the day. How strange that it be Wednesday before lunch and Thursday afterward.
Also for communication you still need to keep a table of when the sun rises and sets in each place; still need to keep in mind "they're x hours ahead/behind."
I travel extensively and work regularly with people in every time zone, and have thought long and hard about this problem. I don't think abandoning time zones is the solution, but abandoning DST globally would certainly help a lot.
Because UTC already exists and is already widely used, and compatible with all existing hardware and software. Rather than commercial Swatch time, I'd prefer French revolutionary time as a decimal time system anyway - https://en.wikipedia.org/wiki/Decimal_time#France
In most cases you're not dealing with people in different time zones. You're dealing with people in the same time zone. With time zones I can figure that wherever I go, daylight is roughly between 7 AM and 5 PM depending on latitude and season, breakfast is eaten in the morning, the midday meal is eaten around noon, the evening meal is eaten around 6-8 PM, offices are open from 9-5, shops are open until around 8-10 PM unless they're 24 hours, people go out for drinks after work between 5 and 7 PM and out clubbing between 10 PM and 2 AM depending on local custom, it's considered impolite to call someone on the phone after 10 PM, and a million other small facts. I live in Seattle now, but if I lived in Boston next week, I wouldn't have to learn all these things over again, at least not to as severe a degree. And if I want to call my friend in Boston, I just have to add three hours to figure out whether it's later than 10 PM Eastern. Any other means of solving the problem would probably be equivalent to using time zones, just more complicated--"well, on the West Coast it's a little late to be calling people on the phone at 0600, and the East Coast experiences local noon at 1700 rather than 2000 for a difference of 3 hours, so 0300 is a little late to call someone on the East Coast".
But there is a very good reason why 12:00 should be midday, it's the mid of the day where the sun is highest in the sky. Actually this fact was enough reason for me to switch my timezone to that of a country on my longitude where there's no DST.
I understand the reason for abolishing DST, but that's not the same as abolishing localtime and timezones all together.
While this is true, every locale in West China essentially runs on "pirate" time, which is adjusted as if it was in its own timezone. So yes, trains and planes are scheduled and run on Beijing time, but everyone else adjusts the time to something that makes sense.
Articles that debate DST always seem to have some strange anecdotal comment that doesn't make any sense. This article has a couple, but I would love to see the source for: "Many farmers still don't like DST, including some dairy farmers, who find that cows' natural milking schedules don't adapt easily to a sudden shift."
Farmers aren't stupid and cows can't tell time. Do you really think they adjust the actual time they milk cows in order to observe DST? A schedule on a farm has far more to do with actual daylight hours regardless of the official "time".
However, they did get the sentiment correct. Farmers have always opposed to changing the time twice a year and largely think the whole idea is ridiculous. Case in point, Saskatchewan does not change their time, but permanently maintain the equivalent of DST year round. Tellingly, there is no debate about adopting time changes either.
EDIT: I agree about the weird anecdotalism of a lot of reporting! I find it quite frustrating. Little snippets of fact get repeated and pulled out of context until they're almost meaningless.
Pro-tip for programmers: never, ever try to build your own library to handle DST. You will get something wrong. Lots of frameworks and system libraries handle this for you, and do it pretty well.
This argument "don't build it yourself - you're doing it wrong" is starting to wear off.
Why should I trust the third party library was built by programmers that knew better? What do they know that I don't?
If I ever need to build something that people say others are better at - with no argument backing - I will just ignore them (I'll do due research as in other projects though).
It's not that the programmers who wrote those libraries knew better - it's that they know better now!
Most programmers have a simplistic view of time, and start out writing some library that assumes simple arithmetic can calculate any duration, then they find their library is wrong in many cases, and problems are gradually fixed as they research and learn more about time. A robust time library that gets everything right is not going to be hacked together over a weekend.
Perhaps the parent comment was too strong as it sounded a bit like "Don't try to write a time library you idiot." Writing a time library is fine, if that is your aim. I think the suggestion is rather, don't bother writing a time library that is intended to be tacked onto your main project, as you'll either get it wrong, or waste time you could be working on your actual problem, when others have already solved the time problem.
It's not that the programmers who wrote those libraries knew better - it's that they know better now!
This is exactly right and it has nothing really to do with time specifically. In any area with a lot of edge cases, you'll usually figure out how to get a lot of those edge cases right after you've got a lot of them wrong, so you should prefer to use something that's already gone through this process. Similar advice here [0]:
"Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters."
Related: don't store times as raw strings or integers (a/k/a unix "timestamps") in your database; use a date/time datatype. It will handle time zones if needed, and you get the benefit of being able to use a lot of provided functions to easily add and subtract units of time, calculate intervals, etc.
I once went, "Oh, this time conversion function is simple. I should have it done this afternoon." About a week later I was still writing test cases that broke it.
Using a well debugged time library is worth it. Spend your cycles writing tests for it, if you must.
Personally I'd like to see timezones disappear too. Why does 9am have to be morning in every country? What would be so difficult about everyone in the world sticking to one timezone? Hell we could go all in and start using star dates.
There were some grumblings out of Russia recently with a governor of the eastern Primorye region ( Moscow + 7 hours ) suggesting that they 'cut' this to four hours to ease communication.
If they're going to fiddle around with things like that it would be best just to decouple entirely from the Mean Sun's schedule and adopt a universal time as you suggest.
Bizarrely all official communications and timetables in the Soviet Union were published in Moscow time, across eleven time zones. That made catching a local train in Siberia quite an arithmetic challenge.
"Run everything in Russia on Moscow time" is a localized version of "Run everything in the world on UTC". So the question is, how did it work, and should we port to that?
This will not happen in the real world. There is simply no incentive big enough to make the whole world agree on this. Hell, we can't even agree to slightly reduce CO2 emissions.
Interestingly, though, China works on a single time zone. So for a small-scale case study in how this would work, go live in different parts of China for a year.
I find this a really good argument for it: how are you supposed to know if you call somebody in the middle of the night, if it's noon where you are, and the hour is the same?
By having different time-zones, you need to look it up, but then you have an intuitive way of judging which stage of the day they are perceiving.
No, time-zones alone can't give you an estimate of sleep-times (even ignoring individual sleep patterns for the moment).
Time-zones are related to the longitude of the location You also need to account for the latitude, and the time of the year, because the pattern of day and night depends on all three factors.
Yes, but who gets the better time spots? People are already pissed that time zones are based on England's time, how angry do you think they will be when they get some illogical time zone while the anglo-saxons get to keep the am in the morning and the pm in the actual afternoon?
Why redesign the watches? This problem doesn't exist in the places that use the 24h format (like most of the world around North America). We can use both time formats. I can either say 9 in the evening or 21 and everybody gets it.
Well, when someone asks me what time it is now, I don't say, "The minute hand of my watch is pointing at the 1, and the hour hand slightly past the 3." Instead I translate it to "three-oh-five". Wouldn't be too much of a stretch to say 15:05 instead.
(My point being that many watches and clocks already don't give us the literal time as it's spoken, just a representation.)
Edit: although just to be clear, I don't actually think we should switch to a single time zone. It would cause all kinds of headaches. I just think if in some universe it were to happen, it would necessarily go along with a switch to 24h time.
You can say 15:05 because you know it's the afternoon and so 3:05 translates to 15:05. Now think through how that works when the whole world is on a single timezone.
Junking DST completely is an unimaginative, backward solution to an imperfect system. DST just needs to be improved a bit more. The advent of computerized timekeeping and GPS means that, for the first time since timekeeping began, we can realize the natural benefits of waking the way humans were meant to--with the sun. I call this scheme Human Time.
With Human Time, the sun rises at seven a.m. every day, in every location, regardless of season.
* An hour is still an hour, but every night at three a.m., time skips about a minute or so each day, ensuring that the sunrise always occurs at seven a.m.
* Each state (or cluster of states) maintains their own 2D timezone.
* Your watch/smartphone uses GPS to ascertain the correct date and time zone. From this information it can compute the correct Human Time, and can show you the time in any other zone, or set an alarm for any other zone. Let's face it--the average human doesn't remember differences between today's time zones anyway, and hits Google whenever such calculations are needed. Moving to a more complicated time differencing algorithm will have no negligible effect on travelers.
* All "human" events (working hours, parties, etc.) use Human Time appropriate for their 2D timezone. All machine events use "machine time," which is standard non-daylight, non-slewed time, GMT, used for all things non-human.
* All watches/clocks/phones would also be able to convert to and from "machine time."
From the improved circadian rhythms that such a scheme would engender, I expect a marked increase in mood and decrease in cancer rates, but obviously this is conjecture, and not proven.
The real issue is that people's habit have changed from what they were until a century ago : the advance of transportation has meant commuting times have extended, the advance of lighting has meant it was possible to spend more and more time awake after dark, etc.
The average time during people are awake is roughly 16 hours a day, and these 16 hours used to be aligned with 1pm being the middle of the day, meaning people would seldom go to bed after 9pm, and would usually get up around 5am.
This makes sense as daylight is well balanced between morning and afternoon. And you don't need daylight saving time !
Therefore the appropriate course of action is to set working hours to be not 9am to 5pm but 7am to 3pm, once and for all.
You seem to be assuming that people want to have most/all of their "personal" time after working hours. Couldn't you just as well argue for working hours to be 11-7?
Whoa, I didn't know that was a thing. Now I've got a handy little reference available when the girlfriend complains that I "stay up too late" (past 10pm!).
I like how the article characterises it as a bad thing that people go out in the evening, get social, and enjoy their lives. The article spends a lot of time countering the "DST saves energy" argument (and mostly only fights to a draw, not a win), and absolutely zero countering "DST gives you more time at the long end of the day to enjoy your life".
I never had a problem with it when I was young and carefree but now married with kids.. man DST is annoying. The kids seem to take a good week to adjust and I'm finding I'm still feeling tired an hour earlier than I should 6 days on.
I'm a youngish carefree man and I fucking hate DST. In the summer everybody switches to going to work one hour earlier and, unfortunately, that perfectly screws with my sleeping habits. In the winter, I naturally get up on time to arrive between 10 and 11, but in the summer, if I'm to get enough sleep, I'd have to be at work after 11! And since nobody else has trouble with it, I basically spend 6 months out of every year struggling to get enough sleep.
Was looking for the person who mentions kids. Thank you. The misery of putting a kid to bed an hour early (WHY DAD WHY?) then listening to them rage for about 2 hours due to getting overwrought, just to have to wake them up in the AM rather than wake up naturally. Its miserable and having braved 4 time changes since she became sentient, it gets worse every time.
The misery of putting a kid to bed an hour early (WHY DAD WHY?) then listening to them rage for about 2 hours due to getting overwrought, just to have to wake them up in the AM rather than wake up naturally.
It's funny how opposite some problems can be though! I have the total opposite issue: my kids love going to bed and would happily go at 4pm if we let them, the problem is they want to be up at 5:30am every day.. :-) I can't even think of a single morning in 4 years where I've had to get my eldest up..
Having lived with it and without it, I'm a loud and proud opposer of Daylight Saving.
It seems that the changing of the clocks causes the most problems. I've oft suggested that fans just change their timezone permanently forward - boy does that create confusion among those wanting to argue.
When I first heard of DST I couldn't believe that there are entire countries out there that follow this practice. It seems like it came straight out of a Terry Pratchett novel.
I'm an electrical engineer and the first project I worked in my professional life was a Power Quality Meter, used by the power company at my city, in Brazil.
In our specific case, DST was pretty good at shifting the two main power demands we had at night: lighting and the effect of people going home (taking a heated shower, using elevators...)
I had access to oscillographies at all power stations in my state (which is not small, here is located the biggest hydroelectrical dam in the World, by annual production). It happened that during DST the quality of the power being provided increased.
I'm not arguing here that this is a solid proof that DST is good, but the effect of concentrated demand and the subtle implications that this has on the actual efficiency of the power grid seem to be all too often neglected.
Well, it's a good discussion, and my main point here is that things are not as simple as they may appear at a first glance :)
I get your point. I see it as a pain in the backside from a programming point of view. Managing arbitrary dst changes which keep changing at the whims of political powers is exhausting at best.
Yes, please. We need a movement to eliminate DST. There is no reason why we should force everyone to accommodate the few who enjoy the illusion of longer days in summer. It is easier to allow those to opt into it (you can wake up an hour earlier if you want) rather than force everyone to get up an hour earlier.
There should be a link here to a piece/rant from last year (or at least it made the rounds then, on here as well, I think), I think, where someone passionately, and quite convincingly, defended daylight saving time.
I searched, but I can't find it at the moment. Does anyone else remember what I'm referring to?
In my opinion I would always leave the DST on. Because people tend to go on average in my opinion to bed later than at 8 pm and on average wake up after the dark is long gone. In other words we sleep when there is light. And I think that the argument about spending more gas because people travel somewhere to play and do activities is all but a bad thing. I have a concrete example when people have a hard time exercising outside because it is dark before you come home from a job. So I vote that DST stays always ON.
I find most people that complain about DST actually are complaining about how it gets dark so early. So, they actually want DST year round and dislike standard time.
I like DST, but I recognize that it's there largely for cultural reasons. (It doesn't save much energy.) Summer nights should be light until 9:00pm; that goes back to childhood and just seems "right". (I know that that's an emotional argument with no reasonable backing.) On the other hand, I don't it to be dark at 8:00 in the morning in the dead of winter, so I prefer the reversion to standard time in the winter.
Want proof that it's cultural? It starts in March and ends in November. Lightwise, March is the midpoint while November is almost the darkest part of the year-- but not cold yet. DST follows the temperature, not the light. People wouldn't like it if they left work in darkness during the high foliage season of October. Hell, I wouldn't like that.
What's really going on, of course, is that DST forces everyone to do everything an hour earlier during the lighter months. In companies that care about presence down to exact minutes (thankfully, those are rare in tech) it becomes socially acceptable to work 8-5 instead of 9-6, because everyone is calling 8:00, 9:00. This prevents all that light in the morning from getting wasted, because people are tricked into getting up earlier than they otherwise would. They think getting up at 6:00 is for old people and gym rats, but that's exactly what they do for 8 months out of the year.
People who work the standard workday want: (a) at least an hour and a half of light before they leave for work (typically, 8:30); (b) darkness by one hour before the average bedtime (about 10:45), and (c) as much evening light as possible during the nicest months (April, May; September, October) of the year. DST is the hack that makes that possible.
One could argue, on the other hand, that it would be better for people to just adapt to asynchrony in work and social life and thus make it irrelevant whether we call the summer sunset "7:30" or "8:30"... but most people don't have that luxury.
Yes. I was going to say that people should just get up earlier and quit work earlier to get the extra daylight, but practically speaking, I think doing that without changing the clocks is much harder for most.
North America observes DST two weeks before Europe. DST ends for Australia two weeks before North America (time goes the other way). China does not observe DST. I won't even bother to get into the other countries.
Even disregarding the other issues that DST created (and trust me, there were lots), just syncing up players for events was a giant hassle. Yes, people should theoretically research and know how their time works, but expecting users to sync your events to their time without missing one or two is naive ignorance. Even with mitigations, my staff and I basically spent every DST start/end dealing with a plethora of IRs to the degree of, "why did you change the time?"
I would not miss DST at all.
(We did standardized time quite early on, and did announce in server-time)