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? 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.
Fine, provided you know location, can interpret the database correctly(!) and can update the embedded equipment when the rules change.
Anything to do with calendars is 10% more difficult than you thought. Recursively.
Favourite questions for youngsters: - how many days in a year - how many months in a year - how many hours in a day - how many seconds in a minute Clueless youngsters /usually/ get one of those right; very few youngsters get them all right.
I'm not exactly a youngster, but given the superficial simplicity of your question, I guess I am missing something important. Can you expand a bit on the topic or point to resources that explain all the nitty gritty bits?
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Astronomy buffs will probably get them right ;-). My guesses:
Days in a year:
formatting link
Simplified answer: about 365.2425 days. The ancient Romans approximated this as 365.25 days, handled with a 365-day calendar plus 1 leap day added every 4 years, the so-called Julian calendar. The discrepancy built up over the centuries til it was adjusted in the 18th century (depending on where you were), by skipping 11 days and changing the leap year algorithm slightly, giving the Gregorian calendar now in use.
Try the Unix command "cal 9 1752" or see:
formatting link
Months in a year: I think this is supposed to be the one everyone gets right, i.e. 12, but of course I'm suspicious. I've heard that the one thing that's really stayed constant is 7, the number of days in a week.
Hours in a day: varies slightly, but the period of the earth's rotation (sidereal day) is about 23.9344699 hours (23h 56m 4.09 sec). The solar day is slightly longer (averages just a tiny bit over 24h) but its length varies with the season:
formatting link
Seconds in a minute: 60 but sometimes there is a forward or backward leap second.
I am not a youngster either, and I can have a shot here off the top of my head. My guess is that I'll have missed something.
The number of days in a year depends on the leap year. The rules are, I think:
if (y % 4) { return 365; } else if (y % 100) { return 366; } else if (y % 400) { return 365; } else if (y % 2000) { return 366; } else { return 365; }
There are 12 months in a year (I'm assuming the modern western calendar here, of course).
There are 24 hours in a day.
There are 60 minutes in an hour.
There are 60 seconds in most minutes. But every now and again, there is a leap second, meaning that there are some minutes with 61 seconds. There is no fixed pattern in this - it is based on astronomical observations (whose fine details are chaotic), and decided on by some committee somewhere.
Shouldn't the correct answer be "365 in most years and 366 in leap years," non-integral days being somewhat awkward to implement. Otherwise, we'd tack on not quite 6 hours to the end of the day on 31 December. Which, actually, seems like a rather good idea except for the inconvenience of moving "midnight" around every year. ;-)
That's a good example of the 10% rule for me. I've never come across the 354; was it due to the change from Julian to Gregorian calendar?
Precisely. Most people fail to get that one right.
23 today in the UK :)
I didn't realise 59 was even a possibility, but it hasn't happened yet. I understands why the earth's rotation has slowed from a day being 6 hours, but I don't see how it could speed up!
They usually get 366 days in a year, during my pause after they've said 365.
Apparently not, otherwise I should have managed to locate it by now... :-)
I suppose I'll start some manual service next time some of our users complains (timezone has to be set manually - NTP is also invoked manually but no one complains about that). So far we have sales in only 5 countries so maintaining the data manually should be manageable. I suppose automatic timezone change on a spectrometer which often acquires a spectrum over more than a day will introduce a lot worse problems to the users though.... (the starting moment is recorded in UTC and the acquisition time is in seconds, with extensive dead time correction etc. attributes around it so the measurement will not be compromised but making all the considerations might be harder for the user than manually changing the timezone :D ).
Hopefully not, he has a lot less to say about things here since Bulgaria is part of NATO and the EU. A lot more than most people think though (we have not yet been told what happened to the giant network of KGB agents which used to officially run the country prior to 1989 - so they now run it unofficially, which is some sort of progress I suppose....).
While it was previously possible to add/remove 1 second twice a year, now there are 4 opportunities to do this each year. As far as I know, seconds have been added only once a year and the slowing down has recently been so slow that the time between additions have been several years.
Thanks to Coos to bringing up the alternatives for the Islam and Jewish calendar, there is is quite a time, since I had to include these things in actual programs.
and 25 h next autumn.
That has never occurred so far, might need a huge zunami.
After bothering to check, you are of course right. I suspect my error was based on remembering the occasions when they were added in July rather than January.
There are a number of very large quakes that are known to have shortened the day. However, the 8.9 in Japan produced a delta of only
-1.8us and it's reasonable to expect that the rotational deltas produced by different quakes would be randomly distributed and thus would be expected largely to cancel. So a negative leap second is possible, but highly unlikely.
Might happen if Earth happens to capture an asteroid - but then nobody would notice because they'd be too busy looking at the second moon.
The big question here is WHICH "year", "month", "day", "hour", "minute" and "second". (Are we UTC, UT0, UT1, or something else for the fine scale, and which calendar for the coarse scale, as well as dealing with sidereal or solar periods). If you give poorly defined questions, of coarse you are going to get wrong answers, and I suspect that most of the "wrong" answers you get, would be right under a different definition. (For instance, some systems do not have leap seconds, or need to worry about Day light savings time).
I would regard anybody that gave that answer as someone that had given a good sufficient answer.
All too often I've had to /explicitly explain/ why some days are 23 hours long. That really ought to be have been recognised by /anybody/ that's experienced at least 20 such days!
Anybody that calls themselves an engineer really ought to have heard of leap seconds. Then, if they ever need to, they can find out more detail.
Months in a year? Knowing that 12 isn't the only answer is something that an inquiring intelligent educated well-rounded person ought to know.
There's the timezone database, and code libraries that use it quite successfully. People use and like that enough that some sleazebags with an astrological background (of all things) tried to gain a copyright stranglehold over it around 2011, to reap a profit.
As a fall back, some C libraries also support a fancy domain-specific language that allows specifying the entire behaviour piled into the TZ variable.
The key problem is the same in both cases: the whole DST nuisance, just like timezone handling in general, is a politically dominated pile of utter nonsense. Whatever solution you have will therefore, by default, be wrong the next time you need it because in the meantime some politician or other decided that the system needed "improvement" (as in: it wasn't quite boneheaded enough yet).
So there's really nothing to be done about it but to maintain an automatic update service to distribute (a suitable subset of) the latest timezone DB to your devices. For devices that don't already need such an auto-updater, setting one up just for this would be highly questionable. And of course, their place of work may well prohibit such kind of net access for security reasons.
IMHO the only approach that makes technical sense for any embedded device (here meaning: any device that's not running a full-service general-purpose operating system with user-installable software and always-on network access) is to _not_even_try_. I.e. refuse to admit that not just "daylight saving", but rather the entire concept of timezones other than UTC (or NTP, or GPS --- pick your poison) even exist. The only likely result from trying to handle this pile of nonsense is frustration.
Scientific instruments had better use the only somewhat scientific time scale there is: number of second since {some point in time of your choosing.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.