In article <ob5gj9lfgjpht5ofojqvrc2u8lkdg0lc45@4ax.com>, Rich Webb <webb.ra@example.net> wrote:>On Sun, 30 Mar 2014 05:10:34 -0700, Paul Rubin ><no.email@nospam.invalid> wrote: > >>Nils M Holm <news2009@t3x.org> writes: >>>> Favourite questions for youngsters: >>>> - how many days in a year365 or 365>>>> - how many months in a year12, if we use the Gregorian calendar.>>>> - how many hours in a day24, as long as we stay in the same timezone. Otherwise, any whole 15 minutes from 22 till 26; i.e. 22,22.25,22.5,22.75,23 etc>>>> - how many seconds in a minute59,60 or 61. The non-60 values are used to add/subtract leap seconds.>>>> Clueless youngsters /usually/ get one of those right; >>>> very few youngsters get them all right.That must be the 12 months per year. But only the days per week is perfectly safe.>>> 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: http://en.wikipedia.org/wiki/Year#Calendar_year >>Simplified answer: about 365.2425 days. > >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. ;-)-- mrr
Daylight savings date identification over the net
Started by ●March 30, 2014
Reply by ●March 30, 20142014-03-30
Reply by ●March 30, 20142014-03-30
In article <lh9hrs$omc$1@dont-email.me>, Dimiter_Popoff <dp@tgi-sci.com> wrote:>On 30.3.2014 г. 13:11, upsidedown@downunder.com wrote: >> On Sun, 30 Mar 2014 12:22:10 +0300, Dimiter_Popoff <dp@tgi-sci.com> >> 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. >> >> There is no such thing !! > >Apparently not, otherwise I should have managed to locate it >by now... :-)Indeed. BTDTGTTS.>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 ).From being involved with telecom accounting we made a very good decision early on. EVERY log file has UTC times internally, and as they are forwarded from the various controllers to the accounting systems. The accounting system also works in UTC. The timezones may then be added ona per-user base just before the finished print. Or not. It is simple to make the accounting periods follow UTC in the contracts. -- mrr
Reply by ●March 30, 20142014-03-30
On 2014-03-30, Hans-Bernhard Br�ker <HBBroeker@t-online.de> wrote:> On 30.03.2014 18:48, Dimiter_Popoff wrote: > >> 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.... > > 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. >Why does everyone confuse the displayed time with the time stored in a file or database and assume they are the one and the same ? If possible, you should always store away timestamps in one permanent timezone, say GMT, and then use the timezone database to determine what the local time offset is from that stored time. That way, there are no jumps in the (say) on-disk recorded time regardless of any timezone changes. Linux does this (and I believe Unix in general does as well) and it works cleanly. BTW, I have a VMS background and I have seen first hand the mess that is timezone handling when you assume displayed time equals stored time. :-) Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●March 30, 20142014-03-30
On 3/30/14, 4:13 PM, Tom Gardner wrote:> On 30/03/14 19:21, Richard Damon wrote: >> On 3/30/14, 6:11 AM, Tom Gardner wrote: >>> >>> 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. >>> >> >> 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! >Except that in some domains all days are 24 hours long (or in one case all days are about 23 hours, 56 minutes, and 4 seconds long)> 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. >Unless they are dealing in UT1, which does NOT have leap seconds.> 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. >Yes, knowing that other answers (for other definitions) are possible is good, but for a very reasonable definition of month and year, 12 IS the answer. Looking at other answers you have accepted, you are demonstrating another bias, for example one answer to the number of days in a year is 1/2.
Reply by ●March 31, 20142014-03-31
On 30/03/14 16:36, Tom Gardner wrote:> On 30/03/14 13:27, David Brown wrote: >> There are 12 months in a year (I'm assuming the modern western >> calendar here, of course). > > Trap avoided :) > >> There are 24 hours in a day. > > Not today :)I've been considering GMT, rather than local time. I guess I should have read the title of the thread!> >> 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. > > AFAIK is it astronomical measurements that determine > when a leap second needs to be inserted. In at least > one year, two were inserted. >I didn't know you could get two leap seconds in one year. It is not uncommon to see time utilities, RTC's, etc., that support seconds counts in the range 0..60 so that they can handle a leap second - but not two leap seconds (see "man date" for example - and that's a *nix command, not a recommended google search....). I suppose it is also possible for a lost leap second to give 59 seconds in a minute on occasion.
Reply by ●March 31, 20142014-03-31
On Sun, 30 Mar 2014 15:36:20 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 30/03/14 13:27, David Brown wrote: >> There are 12 months in a year (I'm assuming the modern western calendar here, of course). > >Trap avoided :) > >> There are 24 hours in a day. > >Not today :) > >> 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. > >AFAIK is it astronomical measurements that determine >when a leap second needs to be inserted. In at least >one year, two were inserted.In 1972 one second was added after Jun 30 and an other second after Dec 31. Technically, one could add 12 leap seconds in one year, each after any month, but always only one second at a time.
Reply by ●March 31, 20142014-03-31
On 31.3.2014 г. 01:18, Hans-Bernhard Bröker wrote:> On 30.03.2014 18:48, Dimiter_Popoff wrote: > .... >> 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.... > > 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.I agree basically, the thing is that our spectrometers are completely self-sufficient, they do run an OS (DPS) with its filesystem, UI etc., one can access them from any platform which has a VNC viewer application (windows, linux, android have been used so far). Obviously time is stored as UTC - in directory entries, within spectra etc., however one has to deal also with the time for user interpretation. File dates are preferred in local time (usually I suppose, so far so good with that). On spectrum evaluation results the time is accompanied by the GMT offset so there is no ambiguity there either (pretty much like time was defined in rfc822 I think, except for leaving out the leading 0 of the hours - a mistake I have made many years ago which I have not had to fix yet and leave so in the hope the world will catch up with my better representation :D :D ). Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by ●March 31, 20142014-03-31
On 31.3.2014 г. 01:38, Morten Reistad wrote:> ... > From being involved with telecom accounting we made a very good > decision early on. EVERY log file has UTC times internally, and > as they are forwarded from the various controllers to the > accounting systems. The accounting system also works in UTC.This is the only sane solution, this is how DPS (the OS under which our devices work) maintains time. In the newer (longnamed) directory entry type time is stored in uS since Jan 1 1970, 64 bits. Current devices do not support the entire precision but the format is there. Older (shortnamed) directories store seconds. Somewhere in the 90-s (the initial format of the shortnamed - 8.4 - directory entry was set in 1994 or 1995) I had to bite the bullet and change to seconds since 1.1.1970, had not thought enough of it when starting the entire endeavour. I think even now the old format can be recognized and read more or less correctly from old disks...> The timezones may then be added ona per-user base just before > the finished print. Or not. It is simple to make the accounting > periods follow UTC in the contracts.Yes, once one has the correct unambiguous data representation is just a matter of choice. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by ●March 31, 20142014-03-31
On 31/03/14 03:22, Richard Damon wrote:> On 3/30/14, 4:13 PM, Tom Gardner wrote: >> On 30/03/14 19:21, Richard Damon wrote: >>> On 3/30/14, 6:11 AM, Tom Gardner wrote: >>>> >>>> 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. >>>> >>> >>> 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! >> > Except that in some domains all days are 24 hours long (or in one case > all days are about 23 hours, 56 minutes, and 4 seconds long)Sure, but that is not everyday (or perhaps every semiyear!) experience for the "man on the Clapham omnibus", whereas 23/24/25 is (except '68-'70 in the UK!). If they can't get everyday experience right, there's no point in considering the "subtleties"!>> 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. >> > Unless they are dealing in UT1, which does NOT have leap seconds.If they know the concept of UT1, they'll know the rest - or at least know they have to go and research the answer. That's fine by me.> >> 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. >> > > Yes, knowing that other answers (for other definitions) are possible is > good, but for a very reasonable definition of month and year, 12 IS the > answer.I'm not aware of anything other than 12 being used for civil purposes, but some calendars do contain 13 months.> Looking at other answers you have accepted, you are demonstrating > another bias, for example one answer to the number of days in a year is 1/2.Unless you're thinking of non-terrestrial calendars, you'll have to explain that one!
Reply by ●March 31, 20142014-03-31
On 31/03/14 10:48, Tom Gardner wrote:> On 31/03/14 03:22, Richard Damon wrote: >> On 3/30/14, 4:13 PM, Tom Gardner wrote: >>> On 30/03/14 19:21, Richard Damon wrote: >>>> On 3/30/14, 6:11 AM, Tom Gardner wrote: >>>>> >>>>> 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. >>>>> >>>> >>>> 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! >>> >> Except that in some domains all days are 24 hours long (or in one case >> all days are about 23 hours, 56 minutes, and 4 seconds long) > > Sure, but that is not everyday (or perhaps every semiyear!) > experience for the "man on the Clapham omnibus", whereas > 23/24/25 is (except '68-'70 in the UK!). > > If they can't get everyday experience right, there's no > point in considering the "subtleties"! > > >>> 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. >>> >> Unless they are dealing in UT1, which does NOT have leap seconds. > > If they know the concept of UT1, they'll know the rest - or > at least know they have to go and research the answer. That's > fine by me. > >> >>> 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. >>> >> >> Yes, knowing that other answers (for other definitions) are possible is >> good, but for a very reasonable definition of month and year, 12 IS the >> answer. > > I'm not aware of anything other than 12 being used for > civil purposes, but some calendars do contain 13 months.13 months makes sense for calendars based on lunar months, although of course there are not exactly 13 lunar months in a year.> > >> Looking at other answers you have accepted, you are demonstrating >> another bias, for example one answer to the number of days in a year >> is 1/2. > > Unless you're thinking of non-terrestrial calendars, > you'll have to explain that one! >No need for an explanation, then :-) (It's Mercury, to save you looking it up.)
