Update your timezone defs: Russia abolishes winter time (DST)
timeanddate.com
timeanddate.com
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.
Oh, and then you also have to convince every other government to implement, too.
(If you don't get it, think about it longer.)
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.
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.
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.
Though actually, you are not really arguing for a large base, but for unary. (Or a mixed unary-large base system.)
I've tried to explain it to people before, but we never manage to count past four without someone laughing.
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.
"See you in the conference room in 2 ksecs..."
Put a bunch of geeks together too long and this is what happens.
http://www.google.com/search?q=fortnight+/+1000
1 fortnight / 1000 = 20.16 minutes
And loads of date parsing / string emitting libraries already handle it :)
Time is a pain in the ass.
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.
i think it might be slightly worse in that "solar noon"-zones would stick to straight bands.
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.
Ürümqi Time (UTC+6), two hours behind Beijing. Although this is not officially recognized, it is the time observed locally by most residents.
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 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 :)
Software is often written in ignorance of this fact - and causes headaches whenever things change.
Like it just didn't, in Russia.
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.
"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!"
I would go so far as to say that farmers hate DST more than programmers/sysadmins do.
She said we shouldn't adopt DST because the extra hour of sunlight - and I quote directly here - would "fade the curtains".
It's summer time that is moved.
Maybe that's only in the US and Russia has the reverse?
As Moscows longitude is 37 degree East, they should really use UTC+3 as their standard time, but that's a different story.
Haven't made the jump yet, but it's only a matter of time before some stupid DST error fills me with enough rage.
Seriously, I wish we all went to GMT, everywhere, and just were done with it.
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.
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.
There is huge variation in these sorts of things worldwide. See, for example, http://www.spanish-town-guides.com/Opening_Hours.htm
(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)
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...
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.
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.
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.
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?
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.
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.