Japanese tower clocks (temporal hour clocks)

[IronWing]

These things are cool. Back in the good old days the Europeans used a system of counting the hours of the day where there were always exactly 12 hours of daylight and twelve hours of nightlight with the length of hours of each varying with the seasons. With the invention of the escapement clock, the Europeans eventually dumped that system for one with constant period hours as it was very difficult to accommodate variable hour lengths with a constant beat clock. The Japanese also used a system of variable hours but when the escapement clock came to Japan they didn't give up the variable hours but came up with some cool clock designs to work with the seasons.

Here are a few samples.
One.
Two.
Three.


http://en.wikipedia.org/wiki/Japanese_clock

Anyway, I was reading a book on the development of clocks and thought these were neat.

 

[IronWing]

Well, I went into total nerd mode over the past couple days and have written a temporal hours sun clock script based on sample one above.

Here's a screen shot.

The graph has days of the year running along the horizontal axis and hours of the day running down the vertical axis (morning is at top). As it is a solar clock it only works for daylight hours. By definition, on a temporal hours sun clock, sunrise is at 6am and sunset is at 6pm so the highest and lowest lines mark sunrise and sunset. The duration of hours changes throughout the year as the sun rises and sets earlier or later. The sun position on the graph above is for Feb 14, 7:45am and is based on my home latitude and longitude. Since it is night at the moment where I'm at, I'll have to wait until morning to "go live" with the actual current time though I know all the parts work and so all should be well.

My original thought was to have the program generate the graph on the fly for any specified lat-long but the perl script I found for calculating sunrise and sunset was written in 1992 and the output has drifted over time so that the calculated solstices are falling in January and July. I had to fall back to using a static table for my lat-long.

I'll pretty up the graphics over the next couple days.

 

[uhohs]

 

[John Connor]

x2.

 

[dighn]

seems like a pretty complicated way to get the wrong time

 

[JEDI]

timex quartz watch $1 at corner street vendor in chinatown

 

[Linux23]

x2.

x3

 

[IronWing]

seems like a pretty complicated way to get the wrong time

:biggrin:

If you think this was complicated, try making a pocket watch that works this way!

When I first read about these type of clocks I was expecting something like a clock version of the watch above but I found the tower clocks instead. The watch in this video is much cooler but would be a pain in the butt to simulate.

 

[IronWing]

The watch video inspired me...

This clock face adjusts to reflect changing day length. This script is a hybrid though as the clock tells regular time but on a seasonally adjusting face. The time showing is ~11pm. The clock face is twenty four hour time with dots marking every two hours, noon is always at the top and midnight is always at the bottom. This is similar the Japanese watch in the video. The star field rotates to relative day and night lengths, not actual sunrise and sunset times. I'm thinking about changing this behavior to have the star field mark sunset and sunrise. I'm also trying to decide whether to keep the button marker for the current time or to replace it with an hour hand.


When the clock program first starts, the hour indicators are clustered in the center of the clock face and drift outward to their correct positions along the edge of the face.

The other thing I relearned in writing the script is that whoever came up with the idea that bitmap coordinates should be set up with 0,0 in the upper left corner should be beaten severely. Likewise the person who decided that clockwise rotation of bitmaps should be expressed in positive degrees. It makes trig problems a pain in the butt.

 

[John Connor]

What if you could somehow use the randomness of the sunlight on a sensor and input those electrical signals into a random number generator to create passwords? Put your scripting knowledge to good use.

I was thinking about that being this topic is about time and I thought of the sun then scrips, electronics and random number generators.

 

[IronWing]

This is my latest, a bit smaller and prettier. The moon is a placeholder but will become an active moonphase indicator within a day or two. I already have a daily moon phase script I wrote for another project and all the images needed so this shouldn't be too much trouble to implement. The clock is windowless and borderless so it can live on the desktop. The stars are an animated gif layer so they twinkle.

Edit: Moonphase now functional.

 

[IronWing]

Clock start up gif...

Added shooting stars.

 

[lxskllr]

That's kind of cool. Limited use, but cool none the less.

 

[Linux23]

pretty cool.

 

[ElFenix]

Well, I went into total nerd mode over the past couple days and have written a temporal hours sun clock script based on sample one above.

Here's a screen shot.

The graph has days of the year running along the horizontal axis and hours of the day running down the vertical axis (morning is at top). As it is a solar clock it only works for daylight hours. By definition, on a temporal hours sun clock, sunrise is at 6am and sunset is at 6pm so the highest and lowest lines mark sunrise and sunset. The duration of hours changes throughout the year as the sun rises and sets earlier or later. The sun position on the graph above is for Feb 14, 7:45am and is based on my home latitude and longitude. Since it is night at the moment where I'm at, I'll have to wait until morning to "go live" with the actual current time though I know all the parts work and so all should be well.

My original thought was to have the program generate the graph on the fly for any specified lat-long but the perl script I found for calculating sunrise and sunset was written in 1992 and the output has drifted over time so that the calculated solstices are falling in January and July. I had to fall back to using a static table for my lat-long.

I'll pretty up the graphics over the next couple days.

does your graphic account for the fact that solar days usually aren't 24 hours?

 

[IronWing]

does your graphic account for the fact that solar days usually aren't 24 hours?

Probably not, but maybe. I pulled the sunrise/sunset data from the U.S. Naval Observatory. The site doesn't say if such corrections are built into their data. I did not include them in my calculations.

 

[ElFenix]

Probably not, but maybe. I pulled the sunrise/sunset data from the U.S. Naval Observatory. The site doesn't say if such corrections are built into their data. I did not include them in my calculations.

it's implicit in that data, but not sure how to correct for it.

if you'll notice, even though we're after the winter solstice (so days are getting longer in the northern hemisphere), the sunrise is happening later. that continues through the second week of january (well, in houston).

anyway, you can read up on it here:
http://en.wikipedia.org/wiki/Equation_of_time

 

[IronWing]

it's implicit in that data, but not sure how to correct for it.

if you'll notice, even though we're after the winter solstice (so days are getting longer in the northern hemisphere), the sunrise is happening later. that continues through the second week of january (well, in houston).

anyway, you can read up on it here:
http://en.wikipedia.org/wiki/Equation_of_time

When I first tested the perl script I mentioned above I saw that sunrises were still later into January but I also knew about that effect so it didn't worry me. But when I started calculating day lengths I realized I had a problem as the days were getting shorter into January and longer into July. That's why I dumped the script and went with the table data from the source above. I'll have read up on it some more.