Can we all just have a 24 hour clock based on GMT, no other timezones, and no daylight savings time?
It seems a whole lot easier to change our time format just once and get used to it... instead of half of us changing the clocks twice a year, the other not, drawing all these weird lines all over (grumble India grumble), and keeping track of it all.
What's stopping you? Starting now, whenever you give someone a time, specify UTC. If someone tells you a time that's not UTC, ask them to provide it in UTC.
No! Even better! "Metric time" - a minute has 100 seconds, an hour 100 minutes, a day is 10 hours (100,000 seconds). Makes perfect sense on a space station so we'll have to face it sooner or later.
Instead of changing our clocks, we could just change our numbering system. Having 50 (that's 5 x 12) seconds per minute, 50 minutes per hour, and 20 hours per day seems perfectly reasonable.
Choosing a radix is a balance between the number of prime factors (and brevity) and the number of symbols to keep track of. I think twelve strikes a good balance as well.
In that case 3 is your number. (Because it's the closest number to e, 2.71)
There is a currency based on it (with the provably least number of coins necessary to make any kind of change), ternary logic, balanced ternary is especially cool, etc.
Actually, the best number depends. Basically, you want to have as few operations as possible, but you also want them easy.
Having base b for number n, you need log_b n digits where each digit is an element of (0..b-1). So working on those representations takes something like f(log_b n, b) operations. Where the function f depends on the operation you are looking at.
A good base should keep f small in relation to all n.
One very natural choice for f, I can't remember which at the moment, leads to e being the best base in theory---so 3 being good in practice.
If you are working with something like trees on disk (yes, data structures are very intimately related to numbering systems---read Okasaki's Purely Functional Data Structures for more information) a very big b, i.e. branching factor in this case, like 1024 is useful: Loading a new digit/node from disk into memory takes a long time, but once it's in memory, your operations will be fast.
But 12 only gains you one more factor that's not a power of 2, and is 30 times more difficult to implement (operation tables have 144 cells for base 12, compared to 4 cells for base 2).
Good luck teaching that to a 4 year old, or someone who's barely numerate. Higher bases are better for learning counting because the person can count a variety of small quantities without needing to understand the concept of a number base. It's not that I don't approve of binary counting by hand, but it's hardly useful for beginners or primitive societies.
There's a few ways to do it: as you can see, I like to use the 1/100 as the base unit (it's a little under 15 minutes in current reckoning) and go decimal beyond that since you have a neat percentage as a result, and you can drop off precision as needed.
We often (jokingly) measure time in kiloseconds around my office. As rue points out, that's just a bit over fifteen minutes, so its actually a useful unit.
"See you in the conference room in 2 ksecs..."
Put a bunch of geeks together too long and this is what happens.
The problem is, if you ever need to deal with events before the Big Switchover to 24-hour time, you'd still need to have all the knowledge of previous zone boundaries, offsets and seasonal rules. Any 24 hour time still has to handle leap years and leap seconds.
First, most humans are extremly reluctant to any changes. You see, US are still using imperial units and Fahrenheit scale.
Second, timezones are used for globally-recognizable time of a day. No matter where you are on Earth, 08:00 (by 24-hour scale) is certainly in the morning, and 20:00 is evening.
It's true that 8:00 can be considered morning, but I think that's useful in fewer situations than one might think. You can't know, for example, whether I'll be at the office anywhere near that time so you'll still need to ask if you want to get a hold of me.
Yes, it certainly is. But combined with the first point, it explains why such change just won't happen (unless something really extraordinary happens).
When I think about it, I find it quite depressing how many nice things are out there, we just can't have because of overall human inertia and reluctance to accept any major changes.
What do you mean by "we"? First, you'd have to get all of the states to sign off on this, including the weird ones that half-follow and half-don't-follow the conventions. I'm not even sure if this is something the Federal government could just demand.
Oh, and then you also have to convince every other government to implement, too.
Good for them. It makes much more sense to shift government/business hours if needed than constantly mucking with the time and screwing up millions of software installations.
No. Every piece of software that deals with time in any kind of sophistication needs to have logic to handle it.
I used to work on a share price alerting system where you could say "if the price of stock X goes up by 10% during these hours than alert me", that creates a nightmare when it comes to DST changes. Do you use the timezone of the person who setup that alert (what if they're now in a different timezone do you change ?) or do you use the DST rules of the country the share trades in.
Imagine you have a calendaring app and someone from another country sends you a meeting request for the future that's past a DST change in one of your countries, but not past it in the other. It's possible for the time to be ambiguous unless you specify DST handling rules. What happens if a country changes DST rules (this happens far more often than you think) how do you adjust previously set appointments ?
Imagine your Google Analytics, what timezone do you save analytics data in and do you adjust for DST (the answer is PST by default, and if you change it, historical data won't be adjusted so you end up with a mishmash of time data).
In any scenario where you have to handle timezones it's complicated enough as it is, DST handling makes it a nightmare.
Unix-like systems like Linux and OSX handle that very well.
The hardware real time clock ticks in UTC, file timestamps and the like are stored in UTC. The OS knows everything about time zones and DST and therefore can display the time the way you expect it.
The problem goes the other way. If a user says, "run this job at 1:10AM", does the job run twice when 2am becomes 1am at the DST switch? If everyone input times in UTC, it would be fine, but users want to input and output.
I am lucky to be able to avoid this problem, because while I do have users that want to read and write times in their local time zone, they are asleep at 1am and automated stuff tends to run at midnight. Sometimes the dice roll in your favor :)
Current time is only a small part of time handling, practically every crontab implementation handles DST differently due to the ambiguity in the posix standard which just states that time stamps have to be in local time taking no account that this can mean a scheduled task can incorrectly get run twice or never.
Not really. On *nixes, there's a library called zoneinfo (http://en.wikipedia.org/wiki/Tz_database) that has the list of rules about "if you're in living in California, then DST starts on March 23" or whatever. When a country changes the law about when DST is, that data needs to be updated.
That can cause headaches, if you have a mission critical system that needs to be updated, otherwise it may do something important an hour early, or an hour late. For example, Postgres has to be rebooted when the timezone information is changed.
Software is often written with the assumption that time always goes forward, because, well, that's how time works. However, according to the rules of daylight savings, time actually goes backwards once a year.
This was resolved a long, long time ago - it's why we have a timezone file, so we can keep the system in GMT and have it convert user-interface stuff for the user.
Software is often written in ignorance of this fact - and causes headaches whenever things change.
If by "automatically", you mean "after thousands of man-hours have been taken to implement and debug the process" - and then only for so long as the system remains precisely the same.
As far as I know there is no such thing as winter time.
Russia had standard time (UTC+3) in winter and changed to daylight savings time (UTC+4) at same dates as the rest of Europe. Now they decided never to switch back to UTC+3 but stay UTC+4, effectively making UTC+4 Moscow standard time.
As Moscows longitude is 37 degree East, they should really use UTC+3 as their standard time, but that's a different story.
You simply have to present it to the Right in the way they can hear it.
"Are you gonna let a bunch of commies beat you in the modernization of time? We didn't land the first man on the moon just so we can be beaten out by savages with beet-powered potatoes!"
Actually the farmers in my family have to reprogram their clocks twice a year to avoid DST, since cows are incredibly sensitive to their milking schedule and the twice-a-year hourly shift really screws with the herd.
I would go so far as to say that farmers hate DST more than programmers/sysadmins do.
I think one of the problems is that the milk trucks and the rest of the industry do respect DST so if you lose one hour the milk might spoil. At least it's what I heard a farmer say on the TV a couple years ago.
This is where I get to offer a famed quote from one our politicians in Queensland, Australia, who was arguing against daylight saving when Queensland was considering adopting DST in the 1980s.
She said we shouldn't adopt DST because the extra hour of sunlight - and I quote directly here - would "fade the curtains".
Indiana just went to daylight savings a couple of years back. Pissed me off - the new Republican governor said it would attract jobs (which is the reason anybody ever does anything in Indianapolis), and the success of that was predictable.
I live in the Pacific time zone, and for a long time I've been tempted to reset my clock to Pitcairn Island time, which is just like Pacific time, but without observing daylight savings.
Haven't made the jump yet, but it's only a matter of time before some stupid DST error fills me with enough rage.
I am not observing DST this winter. When living off the grid on solar power, messing with the time the sun is up is annoying. It's been working out well enough for me. Did a custom DST-less EST timezone. http://kitenet.net/~joey/blog/entry/howto_create_your_own_ti...
It costs the US economy billions every year. Exactly how many billions depends on how you measure, but the direct costs of adjusting for the extension in 2007 were $1.1bn, according to the well-sourced Wikipedia article on the subject. DST all year round, say I. Dark winter mornings are OK by me.
I'd rather say that they are changing their time zone from UTC+3 to UTC+4. It's not that they will have permanent DST, but rather standard time is now UTC+3 and will be UTC+4.
Move to Arizona. We don't have DST here. It's awesome... until you get a machine shipped to you from somewhere misconfigured with DST turned on running a time-criticial task...
Seriously, I wish we all went to GMT, everywhere, and just were done with it.
Isn't winter time the standard clock and it's summer time that is the deviation from that? So Russia would be abolishing summer time that is also known as daylight savings time?
Absolutely, but that is no counter argument to yason's statement. There is no such thing as winter time. As far as I understand it it's just that Moscow's time zone is UTC+3 and they are changing that to UTC+4. It's not that unusual that a country is in an another time zone than it should be geographically, look at Spain for example.
From the article,they only said they won't be switching their clocks back this winter as they usually would.
They have "winter time" in the same sense that "it's the time we use in the winter"
Remember, some places refer to daylight saving time as "blah summer time"
So yeah, all they're saying is they are staying on their equivalent of DST starting this year.
Ho-hum. Want to be really forward-thinking? Follow the example of China, which discarded 5 time zones for a single national time in 1949. (We'd then adjust the office/retail hours to mimic local daylight, rather adjusting the numbers on the clock.)
Parts of Western China observes "Urumqi time" (UTC+6, compared to Beijing's UTC+8). There's a point at which people won't let you screw with their clocks arbitrarily.
One timezone covering enough longitudinal variation to want five timezones is a dumb idea. Doing the same thing in a country with enough east-west span to cover ten timezones would be an incredibly dumb idea.
What, why? Does waking up at 6 have any different intrinsic value than waking up a 3.5 or 11 ? Ever since time zones, there hasn't been an intrinsic meaning to time (who uses sun dials?) We should all just be on the same time, the whole world around.
Indeed. It can also be explained as a matter of simple efficiency: Currently when synchronising something, two pieces of information must be known (the time, and the timezone). If using a single timezone, only one is required (whether it's night or day at either end is inconsequential, only the party at that end really needs to worry about it and can provide a range of hours suitable to them).
This is absolutely incorrect. Except in the singular example of arranging telecommunication across timezones, you have to maintain MORE information under this system. When I currently travel, I can make the assumption that any restaurant will be open by 11 AM, that I have to check out of my hotel by 11 AM and that I can't check in until 3 PM.
In your system, standard store hours have become a random regional fluctuation instead of a strictly maintained standard. I still need to maintain timezone information, but I ALSO need to do math in my head to figure out if it is an appropriate time to go to a certain kind of store.
I don't know which of us is “correct”, but I disagree with your opinion on the matter.
You're making an assumption of a standard time of day when stuff's open (I agree, 11:00 is a reasonable assumption). I can, however, make that same assumption. In your travel model, the traveler must know the timezone (and work with assumptions from there). In my mode, the traveler would need to know the “standard daytime hour” and work with assumptions from there.
So, both require one piece of info when traveling, but a single timezone wins out when synchronising.
Which of the three isn't (generally) true all over the world:
o Restaurants open at 11:00 AM.
o You check out of your hotel no earlier than 11:00 AM
o You can check in at 3:00 PM.
Certainly different hotels allow things like Early Checkin (I've checked in as early as 8:00 AM in hotels with a lot of vacancy), and late checkout (most hotels will let you check out at 12:00, and for a small fee, 1:00 is usually no problem). And yes, there are lots of restaurants that only do dinners, or breakfasts/lunches - but for a restaurant that does two shifts - 11:00 AM is usually a guaranteed time for it being open.
But, I don't think I've ever been to a country where the checkin/checkout/restaurant opening wasn't generally true.
Admittedly, I haven't been to the "One Time Zone China" - that might throw my theory out the door...
Pretty much none of those are generally true across Europe.
Restaurant opening hours vary dramatically by country, largely due people tending to eat at very different times in different countries. To pick a restaurant I walked past yesterday: http://www.restaurant-thierry.fr/index.php?p=contact — open 12pm–3pm and 7pm–11pm. From my experience here those lunchtime hours are fairly common, although more restaurants would open earlier than than in the evening (unlike Spain, where lots of restaurants don't open until at least 9pm or 10pm at night).
On the assumption that #2 is "no later than", then where there's consistency at all it would be noon, rather than 11am.
Check-in has almost no consistency at all. I'm currently in France, and lots of the hotels I've been looking at have a 6pm earliest check-in. Many others are noon or 1pm. I haven't seen one yet that's 3pm.
That's a cultural issue, and Spain has only one time zone anyway. A lot of business can be conducted across the United States, which is fairly consistent in its hours. I suspect that Russia is fairly consistent within their borders as well.
The cultural issue is the entire point here, so it can't really be brushed away. The idea that pretty much any list of things could be true worldwide falls down rather quickly.
Either way, you have to adjust something. Right now, you adjust your known time difference (i.e., change the clock, either by knowing the difference or by asking someone local). With that proposal, you would adjust the known opening times.
With a single timezone then you need to know the longitude of the remote location instead. There's a book (called Longitude, unsurprisingly) about the piecewise invention of accurate chronometry in order to solve the problem of knowing your longitude at sea. Latitude you can work out pretty easily as long as you have an almanac, compass, and a protractor, but longitude is a problems sans clocks and logs of distance traveled.
Ah! You're right -- but a lot more civilian-visible things (train schedules, etc.) were specified in Moscow Time throughout the USSR, whereas in the US it is very rare to use Zulu time/UTC or even DC time for anything.
You're assuming your conclusion ("want five timezones"), and calling the alternative 'dumb' and 'incredibly dumb' isn't much of a reasoned justification.
Why is adjusting the clock numbers better than adjusting local practices?
Why does a single time work well for China... and the US armed forces globally?
Shouldn't we be optimizing for long-distance collaboration, now that we have the telecom technology to do so?
You can generate a table of sunrises and sunsets from the US Naval Observatory, http://aa.usno.navy.mil/data/docs/RS_OneYear.php . Unfortunately I don't see a way to link directly to the table; Moscow is 55 45 N, 37 36 E, and now four hours east of Greenwich. From their location, they're "naturally" around UTC+2:30 (37.6 degrees, divided by 15 degrees per hour).
The table says that in late December the sun will rise at around 10 AM and set at around 5 PM. This doesn't seem preferable to the 9-4 they'd have under standard time. I'm not sure about Russian time zone boundaries, though; is Moscow time used in areas to the east of Moscow?
That's a lot of real estate under one time zone, it may be silly to have summer and winter times but having one time zone for a country approximately the same size as Canada (5,000km wide) seems silly, Canada has six time zones.
> having one time zone for a country approximately the same size as Canada (5,000km wide) seems silly
Why?
In America, people already get up at 7am (insert your own time here, obviously) regardless of what the local sunrise actually is - which varies based on how far north or south you live.
It's pretty arbitrary. But one time zone at least makes the arbitraryness easier on coders.
It's arbitrary to a degree, but having a single timezone for Russia, or even the US, would amplify the effect. It's no big deal now because you are used to season changing, sunrise changing, etc - but if suddenly you had to get up for work and endure, say, 5 hours of darkness, or perhaps only 1 hour of daylight left..... it would be ugly. That's why we have timezones.
Couldn't you just get up at, say, noon, work from 2pm until 10pm, and go to bed at 4am? This would be a bit confusing at first but it's basically what people do now. Solar noon would be at a different chronological time for everyone outside of GMT but you'd only have to make the adjustment once, plus it would provide an economic stimulus to compass manufacturers :-)
Yes, this is exactly what I meant. I didn't mean that the whole country would get up at 8am, no matter what the local solar time was. That would be kind of ridiculous.
Hope that Berlusconi in one of his delirious of madness will do the same for Italy. But I want to stay always in DST, that in Italy means more daylight.
The problem is that the rest of the world will instead follow the clock. So for instance my son will still exit school at 2:10 pm, I'll need to prepare something to eat, and then we could spend some time to the park, but it's already too late to get some decent sunlight.
.svg){kind=link}
It seems a whole lot easier to change our time format just once and get used to it... instead of half of us changing the clocks twice a year, the other not, drawing all these weird lines all over (grumble India grumble), and keeping track of it all.