Update your timezone defs: Russia abolishes winter time (DST)(timeanddate.com)
timeanddate.com
Update your timezone defs: Russia abolishes winter time (DST)
http://www.timeanddate.com/news/time/russia-winter-time.html
15 comments
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.
Well while we're at it, what's the fetish with 10? We should use powers of 2 for everything :)
I would prefer base-12; it has a lot of benefits. See http://en.wikipedia.org/wiki/Duodecimal, especially http://en.wikipedia.org/wiki/Duodecimal#Comparison_to_other_...
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.
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.
I'd like to use base-11. Prime numbered bases eliminate lots of special cases.
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.
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.
Why is being close to e a good thing?
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.
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).
Most of us have 10 fingers, which makes counting easy (although you can count to 12/20/24/40 on your fingers too, I admit).
Why stop there? Lets have base 1024, you can count to that on your fingers too!
http://en.wikipedia.org/wiki/Finger_binary
http://en.wikipedia.org/wiki/Finger_binary
No, you can represent it with your fingers but not count it. By 'count' I mean an ordinal traversal of the sort you teach kids.
Use gray code.
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.
Oh, for that application, my suggestion of gray code is even worse then binary.
Though actually, you are not really arguing for a large base, but for unary. (Or a mixed unary-large base system.)
Though actually, you are not really arguing for a large base, but for unary. (Or a mixed unary-large base system.)
Powers of ten are easy to manage in base 10?
Yeah, but once you move everything to base 2, you won't have to deal with those pesky powers of 10 anymore ;)
Base 2? Nonono, everything is always base 10.
(If you don't get it, think about it longer.)
(If you don't get it, think about it longer.)
Not in gray code.
[deleted]
We should also use base-8 number system! http://infoverse.org/octomatics/octomatics.htm
http://decimalti.me
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.
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.
"See you in the conference room in 2 ksecs..."
Put a bunch of geeks together too long and this is what happens.
decimal time (using SI prefixes to the regular second) is regularly used in (physical) engineering disciplines.
Real geeks use milli-fortnight
Indeed.
http://www.google.com/search?q=fortnight+/+1000
1 fortnight / 1000 = 20.16 minutes
http://www.google.com/search?q=fortnight+/+1000
1 fortnight / 1000 = 20.16 minutes
Already done: http://en.wikipedia.org/wiki/Swatch_Internet_Time
And loads of date parsing / string emitting libraries already handle it :)
And loads of date parsing / string emitting libraries already handle it :)
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.
Time is a pain in the ass.
Time is a pain in the ass.
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.
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.
Even China, which is officially on one timezone, has local "un-official" timezone.
That's very interesting, I had no idea. Could you elaborate?
from:
http://en.wikipedia.org/wiki/Time_in_China
Ürümqi Time (UTC+6), two hours behind Beijing. Although this is not officially recognized, it is the time observed locally by most residents.
Ürümqi Time (UTC+6), two hours behind Beijing. Although this is not officially recognized, it is the time observed locally by most residents.
And in Russia timetables on all railway stations throughout the country are Moscow time. Even in the Far East regions.
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.
your second point seems interchangeable with the difficulty of knowing what timezone some random location falls into.
i think it might be slightly worse in that "solar noon"-zones would stick to straight bands.
i think it might be slightly worse in that "solar noon"-zones would stick to straight bands.
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.
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.
Oh, and then you also have to convince every other government to implement, too.
[deleted]
What? Then some musician would have to work during the day and sleep at night.
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.
can't the OS's handle the change automatically?
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.
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 :)
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.
For example, last year Chile gave a month's notice that daylight savings time was changing. (http://www.timeanddate.com/news/time/chile-extends-dst-2010....)
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.
For example, last year Chile gave a month's notice that daylight savings time was changing. (http://www.timeanddate.com/news/time/chile-extends-dst-2010....)
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.
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.
Like it just didn't, in Russia.
Like it just didn't, in Russia.
Sure, but it's just another point of failure for dubious benefit.
That's a great precedent! I hope the US abandons winter time, too.
Winter time is the standard time (i.e. based on solar noon).
It's summer time that is moved.
Maybe that's only in the US and Russia has the reverse?
It's summer time that is moved.
Maybe that's only in the US and Russia has the reverse?
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.
As Moscows longitude is 37 degree East, they should really use UTC+3 as their standard time, but that's a different story.
More likely this will deter Congress from taking action, out of spite.
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!"
"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!"
Lousy farmers...
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".
She said we shouldn't adopt DST because the extra hour of sunlight - and I quote directly here - would "fade the curtains".
Okay, that was a bit too subtle:
http://www.snpp.com/episodes/3F05.html
http://www.snpp.com/episodes/3F05.html
Farmers work whenever they want.
And people haven't been using farm schedules to justify DST for several decades. It's now supposedly about electricity use.
It's about continuing to justify what has always been a bad idea of which the powers that be refuse to let go.
It's probably not about farmers: http://skeptoid.com/episodes/4172
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 would go so far as to say that farmers hate DST more than programmers/sysadmins do.
Why do farmers bother they cows with DST, then? Can't they just get up at the same (real) time?
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.
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...
I wish they would do that here. As a parent of two small kids I dread the clock changes, it takes forever for them to adjust.
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.
As a father, I completely agree. As a c++ developer I'm counting down to the russian support calls.
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.
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?
No. Per the article, they're staying on UTC+4 (aka DST) permanently, rather than falling back to UTC+3 in the winter.
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.
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.
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.
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.
You obviously don't travel much.
There is huge variation in these sorts of things worldwide. See, for example, http://www.spanish-town-guides.com/Opening_Hours.htm
There is huge variation in these sorts of things worldwide. See, for example, http://www.spanish-town-guides.com/Opening_Hours.htm
Which of the three isn't (generally) true all over the world:
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...
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.
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.
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.
(PS Spain has multiple timezones: http://www.timeanddate.com/worldclock/city.html?n=141 vs http://www.timeanddate.com/worldclock/city.html?n=683 for example)
(PS Spain has multiple timezones: http://www.timeanddate.com/worldclock/city.html?n=141 vs http://www.timeanddate.com/worldclock/city.html?n=683 for example)
When you travel, how do you know what time it is?
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.
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.
Why are timezones a good idea? 12:00 is not solar noon for essentially everyone.
USSR did exactly that, historically (there was one time; Moscow time).
No. USSR was always divided into several time zones. Moscow time is just a soviet analog of GMT.
http://en.wikipedia.org/wiki/Time_in_Russia#Developments
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?
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?
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?
Moscow time is used in the North-West region, there are 9 time zones in total: http://en.wikipedia.org/wiki/File:Map_of_Russia_-_Time_Zones...
.svg){kind=link}
[deleted]
[deleted](1)
China also maintains the same time year round.
Yes but for the entire country!
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.
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.
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.
If you want to get up an hour earlier to have more light, then just get up an hour earlier.
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.
Woohoo! Good riddance.
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.