On Wed, 02 Apr 2014 23:31:50 -0400, Richard Damon <Richard@Damon-Family.org> wrote:>On 4/1/14, 5:09 AM, Tom Gardner wrote: >> On 01/04/14 03:48, Richard Damon wrote: >>> Then why were there questions about seconds in a minute or hours in a >>> day, these are not calendar questions either. >> >> The number of hours in a day depends on the day of the >> year - hence calendar information is inherently required >> That is reflected in the API of software libraries; many >> default to a particular locale but allow you to set the locale. >> >> >Actually, if you look up the definitions of hours, and day, you should >find that for most reasonable definitions of "day", you will get that a >day is 24 hours (for earth) for EVERY day. It is only for this strange >beasty of a "calendar day", or something artificial like "wall clock >time" that we get the exception, and this strangeness. You also need to >add into the equation where you are talking about, as there are >locations which never to this shifting, and others that do it at other >times, so just having a calendar isn't good enough.While the _mean_ solar day is exactly 24 hours or 86400 seconds, the actual solar time as measured by a sun dial or more scientifically using a telescope to detect when the sun is in south (actually in the meridian, depending on hemisphere) is not constant, but can vary nearly a minute, causing +/-20 minute cumulative difference between actual solar time and mean solar time twice a year and slightly smaller peaks in between. Before railroads and telegraphs, each city used their own mean solar time. There was a small village outside London with a naval observation, which their own local _mean_ solar time, which later became GMT (after changing definition from noon-to-noon to midnight-to-midnight :-).
Daylight savings date identification over the net
Started by ●March 30, 2014
Reply by ●April 3, 20142014-04-03
Reply by ●April 3, 20142014-04-03
On 03/04/14 04:31, Richard Damon wrote:> On 4/1/14, 5:09 AM, Tom Gardner wrote: >> On 01/04/14 03:48, Richard Damon wrote: >>> Then why were there questions about seconds in a minute or hours in a >>> day, these are not calendar questions either. >> >> The number of hours in a day depends on the day of the >> year - hence calendar information is inherently required >> That is reflected in the API of software libraries; many >> default to a particular locale but allow you to set the locale. >> >> > Actually, if you look up the definitions of hours, and day, you should > find that for most reasonable definitions of "day", you will get that a > day is 24 hours (for earth) for EVERY day. It is only for this strange > beasty of a "calendar day", or something artificial like "wall clock > time" that we get the exception, and this strangeness. You also need to > add into the equation where you are talking about, as there are > locations which never to this shifting, and others that do it at other > times, so just having a calendar isn't good enough.Oh good grief. If you want to play silly games with 'most reasonable definitions of "day"', then a terran "day" lasts /anywhere/ between 0 and 24 hours. To take merely the first line of the first google hit day noun 1. the interval of light between two successive nights; the time between sunrise and sunset from http://dictionary.reference.com/browse/day and consider anywhere in the arctic or antarctic.>>>> Do you have any pointers to non-terran calendars? >>> >>> Here are some found with a bit of searching. >>> >>> https://home.comcast.net/%7Edoowopdon/klingon_history.htm >>> >>> http://www.marketaz.co.uk/StarTrek/Vulcan/calender.html >>> >>> http://calendars.wikia.com/wiki/Middle-earth_calendar >>> (well, this MIGHT be considered terran) >> >> Um, I was looking for something with at least a >> tiny basis in reality. >> >> >>> Of course, until we get to some other planet, or meet someone who has, >>> these will be be a bit academic. The "Working on Mars Time", was >>> interesting, while the period was short enough they really didn't get to >>> calendars, they did get to clocks. >> >> I suspected as much. >> >> >>> http://starwars.wikia.com/wiki/Galactic_Standard_Calendar >> >> Anything less fictional? Astrological calendars don't count! > > So, you say that just because you haven't meet the people using the > calendar it doesn't exist?So you would give equal credibility to a nutter using a calendar based on the "ancient day" of 6 hours? (Because the earth's day was originally 6 hours long).> At that point you need to accept that a > person may consider that there are always 12 months in a year, and even > that as far as they are concerned, always 24 hours in a day (they may be > from a place without DST).Strawman argument - very revealing.
Reply by ●May 6, 20142014-05-06
Hi Dimiter, On 3/30/2014 2:22 AM, Dimiter_Popoff wrote:> About every year when it comes to it I search some reasonable > way to implement it and shortly after I give it upand go > empty handed. > Does anyone know how do MS and Android devices do it? > Where do they look the date up?Getting *a* date/time (UTC) is easy! It is then up to the devices themselves to adjust for "local conventions". They would have to periodically update their time zone tables based on geographic and legislative changes. E.g., here (US) there are regions of the country that do NOT observe savings time. And, there have been times when legislation has *altered* the observance of said time changes. In short, you can't code one solution and hope it will always work. Nor is there a "standard"/service that would provide this information to you. As a (non-portable) *hack*, you could query google for "current time" and "<location>" and parse the result. But, there's no guarantee that google will continue to support this query.> Eventually I suppose I'll do some sort of service for > DPS devices myself but it would be > nice if there were something similar to NTP to use.Either allow them to submit a query to you similar to the google one outlined above; or, push updates to the time zone tables periodically (folks who don't connect to you "often enough" don't get the benefit of having the most recent tables) [BTW, this can also handle leap second scheduling] Personally, I find it easier to just maintain a monotonically increase count of "elapsed time" (since some arbitrary epoch) that devices use to know "what time it is". I can tweek the timebase dynamically to track "the passage of time" more accurately (i.e., so one "count", on average, corresponds to the time required for light to travel 299,792,458 meters) but always ensure that "future >= now >= past". How this notion of time is presented to the user is then completely arbitrary (i.e., defined by the application). So, the fact that user time exhibits "discontinuities" is an issue that the *user* deals with and not the device. [E.g., user could decide -- erroneously -- to set the time/date to Jan 2, 2035 4:23PM at THIS INSTANT! Is this "wrong"? Is setting your alarm clock "5 minutes fast" also *wrong*??]
