Daylight savings date identification over the net

What's wrong with just using the timezone database ?

See

Some background information is at:

Simon.

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.

There is no such thing !!

Last night Crimea went from UTC+2 (East Europe Standard Time) to Moscow time (UTC+4 all year around) at UTC 20:00 yesterday.

The rest of Europe did the transition at 01:00 UTC from standard to daylight saving time.

In Microsoft environment, the TZ environmental variable is quite expressive, but who is going to update for your region ? Mr. Putin ?

NTP only carries the leap second warning signal. The daylight saving time is far too political to be handled technically :-(

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?

Astronomy buffs will probably get them right ;-). My guesses:

Days in a year:

Try the Unix command "cal 9 1752" or see:

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:

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.

usually 24

You seem to be quite optimistic.

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.

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.

Trap avoided :)

Not today :)

AFAIK is it astronomical measurements that determine when a leap second needs to be inserted. In at least one year, two were inserted.

Op Sun, 30 Mar 2014 15:31:49 +0100 schreef Tom Gardner:

The Islamic year has 354 and 355 days. The Jewish year has 353, 354, 355, 383, 384, or 385 days.

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....).

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

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.

Large earthquakes.

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.

George

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.