Here's a version that cycles through the colors continuously (without jumps). Now the numbers do not directly corespond to the color code anymore (they alternate going up-down). Also you can multiply by 256, as the maximum is not reached for any of the values.
My quirk is that you can stick a fragment on the end to change the mapping of time to hex. e.g. http://davidlynch.org/toys/colorclock/#smh is seconds=red, minutes=green, hours=blue.
It'd be great if you could add the necessary meta tags to make this fullscreen when saved to home screen on a iOS device. No need for an icon -- iOS already frames the time nicely.
I'm on a P4 3Ghz at the moment, whereby I can hear my CPU buzzing away when its under load. On the .co.uk site the buzzing is audible, its taking >70% of the CPU, whereas on your site its nice and quiet taking just 6% of the CPU.
I can not figure out how such a simple program can manage to take up 100% of my CPU, and despite that not be in sync with my actual clock (it's a random fraction of a second off).
Has he not heard of sleep(1) ? Saying "it's flash" is no excuse, flash is perfectly capable of sleeping.
Updating a clock to display the correct time is actually difficult and involved, sleep(1) will not work! The problem reminds me of this Intel article on syncing video output [1]
Basically, sleep(1) won't always align with clock updates, so sometimes a given time will display for more or less time than a second. This can be observed by opening the clock widget on Windows XP for example, it's very noticeable. I don't actually know a nice way to do it, maybe updating 10 times per second or so?
On POSIX systems, clock_nanosleep() can accept an absolute time argument.
// In a real program one would probably not use time()
// Also, some older pre-release versions of the realtime
// kernel patches had the clock_nanosleep() and time()
// clocks out of sync by 0.5s (IIRC)
for(;;) {
struct timespec after_epoch = { .tv_sec = time(NULL) + 1, .tv_nsec = 0 };
// Check for EINTR in a real program
clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &after_epoch, NULL);
printf("Tick\n");
}
Rather useful in this case could be an adaptive method. First, you update every 50ms until you circled in the moment when the second toggles. Then you can do sleep(1) again and save resources.
Alternatively, use time() to only sleep the remaining timespan until the next second.
Well to get technical there isn't a "sleep" function in flash. The best you can do is use setTimeout, which will call a function back in a specified amount of time. Everything including screen drawing, mouse interaction, effects/animations, code execution, etc all run in a single thread, which means if you could actually sleep(1) it would lock everything up for the full second.
Jim Blandy wrote a similar program for X Windows around 1992: a beautiful color clock that would sit on your desktop's root windown and slowly cycle through the colors over the course of an hour. It didn't even show digits -- you just had to learn the colors :-). I think it depended on X supporting writeable color cells, though, so it would need to be rewritten to work on most modern systems (which generally seem to not be set up that way).
http://svn.red-bean.com/repos/circles/trunk/
Hmm, but that's after I started making some mods. For best results, try an earlier rev (this was converted from CVS, hence the weird log message):
It should be simple enough to implement in HTML - it looks like it's just doing (seconds since midnight × 16777215 / 86400), converting to hex and using that as a colour. Toggling between "clock" and "colour" mode would be a bit more difficult, but doable.
Clocks are a common beginner project in DIY hardware, they are both simple to make and have good potential for adding stuff like RSS readers and so on when you want to branch out.
It would be nice if the colour was meaningful, i.e. if one could, at least roughly, guess the time based on the colour. Say, that the brightness would reflect time of day (brightest at noon, darkest at midnight) and the hue the time within the hour.
A shame that the fastest-moving value is placed in the portion of the spectrum where we have the least colour sensitivity. I'd have put hours in blue, myself. If I'd thought of it.
I'm quite sure there are much more mappings from hh:mm:ss -> rgb which would be even more interesting or even practical.
For sure the internet will iterate on this idea in just a few seconds :)
I'm red-green colour blind but have difficulty in describing colours in general (I see them and know what they are but sometimes (and especially if they're under a coloured light) I can't specifically say what colour a wall is, for example).
This is quite interesting as I can't really see second-by-second changes; at most I can see small jumps (not the radically large ones) you get every few seconds.
I'm not color blind, yet that is what I see, too. Makes me wonder about the brain's color-processing. My guess is small variations are ignored by the brain because slightly changing light conditions can cause all colors to vary slightly over time. Your brain filters them out so you can only tell when something really is changing.
It would be interesting to see what would happen if the colors were given by following a space-filling curve in three dimensions, like the last figure at http://mathworld.wolfram.com/HilbertCurve.html
The hex clock seems to jump every once in a while, probably compensating for the large difference in the number of hexadecimal color values and seconds in a 24 hour day.
How are the color values related to the seconds here?
As I understand: hours are red, minutes are green, seconds are blue. Simply formulated as HTML color #HHMMSS (and with each component scaled appropriately to 00..FF so that 00:00:00 is #000000, 23:59:59 is #FFFFFF)
Though the colours I'm getting are different. I wonder why.