Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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.


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.


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).


That's why you should use the digits -n/2 to +n/2 for base n. That shrinks the tables by a factor of four.


Oh no, I just knew someone would come and argue for balanced n-ary on this thread :)


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


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.)


Because it makes it so that the number four has another meaning that, for whatever reason, people can't get past.

I've tried to explain it to people before, but we never manage to count past four without someone laughing.


Then they're missing a far better number: 132


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.)


Not in gray code.


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.


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.


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


Already done: http://en.wikipedia.org/wiki/Swatch_Internet_Time

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.


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.


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.


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.


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.


What? Then some musician would have to work during the day and sleep at night.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: