Most of the times applying RST will sift your hour pillar by one hour if one uses the 24 1 hr timezones standard. But in the real world , timezones arent geographically the same in shape. Depending on the wideness of the timezone area this can vary as you can see on this attached timezone map, some timezones are huge, like for example china's timezone. Then as timezones arent uniform , the RST formula needs to take this into consideration? Or is there a database to know longitude of the center of each timezone not based on the homogenous 1hr per 15 deg convention.
I appraciate any help on this!
Hi ! : )
These are complex topics. I actually made facebook group with the idea we can go into more scientific/technical parts of the Five Arts, but not ready to open it up yet.
But will try to cover a little of what you ask about, going into all of it is too long for here, especially like this. So lets say we have Latitude and Longitude. As we have to start from something. Getting a place name and/or timezone name from Latitude and Longitude is called Geolocation.
Google and others provide Geolocation services. A site can send them latitude and longitude and they can send back place name. Its free. Problem with it, is that to use a shape of a country , cities and places it uses very large files. One can host that themselves, but there is burden on the server and most smaller sites(like ours) would avoid doing it.
Alternative solution can be to use country shape files. That is what we use. That are shapes that are trying to provide some reference of different timezones, but they aren't perfectly fitted around the borders of places.
The idea here is if someone clicks the map and sees where they clicked is not showing the timezone correctly, they just click a nearby big city and it should work right away.
There are multiple reasons we choose that.
1. People using the site aren't depended on outside service provider like Google, for that specific calculation.
2. Its really fast.
3. It doesn't seem to be a big problem, if people look at the map, it should be very clear if it counts the right place or not.
4. Its very ready to be used offline if needed.
Our alternatives, at that point was, use Geolocation service provider, host our own geolocation databases or like you said use simplified calculations.
First 2 would make it more accurate/aligned. Third will make it more inaccurate, depending on the calculations. Currently, for our scope we ended up with shape files. That seems the best compromise providing full accuracy, if one looks where they click and what timezones show.
How is Daylight Savings calculated after that... Well, DTS is in every browser, so that is easy part, we just check if there was DTS at the time and date they inputed and if there was we subtract it all from the browser itself.
Anyway, on the big question is "Solar Time" more accurate.
In my humble view, in general yes, but its not that simple.
If we live on the poles for example, we have 6 months of daylight(so day becomes a very "big" event). That may not be very accurate to be used. Using "Noon" as Wu Horse hour, suggests Wu horse hour there may take months to end. Something very far from what is calculated in other places.
At the same time if one lives on Diomede Islands, using timezones they may have 21 hour differences with some of the other islands just few miles apart.
Overall - all is not that simple. There are details and tricks and turn arounds... Should we just not worry about time... I think that can backfire at times. While I'm big fan of the idea to not control the process too much, the base can't be too inaccurate to use that consistently, in my humble view.
We have uploaded free scripts to calculate Solar Time using Country Shape Files. That seems to be the best choice, in my view, if one wants Solar Time and doesn't want to use APIs. Code can be modified to use Google Api when it should be close to perfect for most of the Earth. But have to deal with the Poles then.
I will stop here. Its just too long topics to go into, as Geolocation (or simplified calculations) is just a small steps and the whole process involves other steps as well.
What is more accurate - again, not that simple. Its much more complex and I'm not sure there is one solution that will fit all. In my experience, Solar Time is preferable if we want to be sure the chart we read is closer to how it should be and the person wasn't in too unusual place(like the poles).
Yet if people are happy with clocktime I can understand that as well. At the end we all use whatever we find working for us. This isn't something to compete about, as this are very, very complex topics and calculations we are involved into, each with its own problems. We use what we think is best.
