Re: Why the US wants to end link between time and sun


"Dr John Stockton" <jrs@xxxxxxxxxxxxxxxxxx> wrote in message
news:mbnFqnBbPS7CFwuh@xxxxxxxxxxxxxxxxxxxxx
> JRS: In article <uS2He.80170$G8.74731@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
> dated Sun, 31 Jul 2005 11:46:34, seen in news:uk.sci.astronomy, Colin
> Dawson <newsgroups@xxxxxxxxxxxx> posted :
>
>>Making a leap hour won't solver the problems for programmers either. All
>>it
>>will do is puch the rug under the carpet. As a programmer myself I fully
>>understand this part of the issue and can explain it.... Date and times
>>are
>>stored on a computer by using an Real number (that's a number will an
>>integer part, and a fraction)
>
> That's but one way; common, but not good. DOS, for example (and Windows
> too), does it differently.

I never said that it was good, bad or indifferent. Although after the
dicussion today, I'm extremely happy to think that it's a bad way to store a
date time.
But it's not something that will be solved quickly, if ever. Afterall there
are not many applications where accurate time keeping is paramount, and the
pro's of this method are alot more than it's con's. The advantage is that
it's extremely easy to work out the difference between to times, by
substracting one from the other. As it's a floating point (and I've just
checked this. It's stored as a 32-bit floating point) other tricks can be
used to perform calculations on dates, like adding a time offset and stuff
like that. It takes advantage of code which already exists. The big con
however is that it's not possible to take leap seconds into account with
this message. I'll stop there, as it's now going over old ground.

>
>> The Integer part of the date is the number of
>>days from a given Epoch (Normally, 31-Dec-1899, so day 1 is 1-Jan-1900).
>
> That is merely one way of doing it, originated by incompetents of
> manifest nationality. While that was the intention, they forgot to
> exclude 1900-02-29; thus Day 1 is 1899-12-31, local time.
>

I don't know who came up with the method, but it's used by business' all
over the world, and I'm not just talking about Delphi either, the same date
storage method is used in MS-SQL Server for it's datetime data type, Oracle
for it's Date time storage as well. These are references that I know of for
definate, and I'd be surprised if there are not alot more of them, like
every programming language that is currently being used. Like it or not,
it's a standard way of doing things, and programmers like standards, just
look at the mess that needed to be sorted out for the Millenium bug. All
just because the standard way of storing dates in the 50's was to save the
year as 2 digit's, then when working tag the number 19 first. Some programs
would flick to 1900, whilst others would flick to 19100, depending on how
the programmer had implemented the code. Either was it was completely
wrong.

For most applications DateTimes don't need to be stored accurately. Some
applications, store the local time at which the an event occured. However,
this is stored is terms of a command called "now" or in SQL Server
"GetDate()". These command both return the current local time. So in the
winter it'll be GMT for the UK, but in the summer it'll be BST. Use the
command on a machine in the US and it'll return the local time for the given
timezone. To give you some idea of how much most programmers really care
about getting the time saved correctly they will tend to store that time
into the data. Yep, there's no reference as to which time zone it was for,
or if Daylight savings time was active or not. In most instances this
isn't a problem because most business' only tends to run 9-5, so it does not
matter, but for call centers and other 24 hour tasks this does matter.
But most of the software that I've seen simply ignores this issue.

As you can see from that, the floating point storage may not be accurate,
but it's nowhere near as bad as the other problems which may be more
prevelent. I'd bet that it never crosses most peoples minds that this could
even be an issue.

>
>>The time part is stored in the fractional part of the day.
>
> Merely one way - and not a good one, since the day is divided by 24 60
> 60 yet the fraction is binary. Hence a time such as 08:00 or a duration
> of 8 hours cannot be represented exactly in that notation. Note that
> time-of-day is reversed before 1899-12-30, at least as implemented in
> Delphi.

erm, not quite. It's 24/60/60/100, at least in Delphi. It does let you
store 1ms, and can tell the difference.

>
>
>> so 1.5 is midday
>>on 1-Jan-1900, and 1.25 is 6 Am that morning. This is similar to the
>>Julian date format.
>
> You are one day out.

Not in the case of Delphi, here's piece from the Delphi help file.

The integral part of a TDateTime value is the number of days that have
passed since 12/30/1899. The fractional part of a TDateTime value is
fraction of a 24 hour day that has elapsed.

>
> One should never refer to Julian dates without explanation (the Julian
> Calendar is OK). It can rightly be a daycount from noon GMT of 1 Jan
> 4713 BC Julian, or loosely from 0h local on that day for historians; or
> it can be YY-DDD or YYDDD, for which the proper term is Ordinal Date.
>
> <URL:http://www.merlyn.demon.co.uk/moredate.htm#Who>. The more cultured
> readers may have additions for that section.
>

I knew that mentioning the Julian date was a bad idea. I'm sure that the
point of what I was saying has been understood though.

>
>>The problem with a leap hour is exactly the same, as there's no place for
>>it
>>to go. The only possible solution for it would be for a leap day, which
>>would also make programmers crinch, as they'd need to write a routine to
>>add
>>an extra day every few thousand years. But then kids really would be
>>going
>>to school a 4 in the morning.
>
> No. Leap Seconds are used to keep mid-day at 12 o'clock; Leap Days are
> used to keep Summer in the right months (well, Easter, really).

So, if you don't take leap seconds into account won't the time of say
midnight slowly shift? Then after enough leapseconds missed, the whole
thing shift so that midnight occurs whilst the sun is at what we currently
call midday? (cringes, waiting for people to start splitting hairs about
that wording too) There for kids end up going to school at 8 in the
morning, which is still in darkness.

Ah, I get it now. That's why the government's can't be bothered about the
light pollution problem. They want it to be daylight 24/7 so that we can't
tell!

>
>>How to programmers get around the leap second problem? Most of them
>>ignore
>>it! About 90% of the worlds software uses dates and times to record when
>>things happened. Their systems don't aren't accurate anyway, so then
>>something says 30:17:25 is could be anything up to about 5 minutes either
>>way. With atomic clocks now available via the internet, most computers
>>are
>>to within about 2 seconds though.
>
> That'll change if the US changes its DST rules, as Congress has in mind
> <G>.

Bet it won't. The whole thing sounds like another country getting jealous
because Greenwich is used as the based point for the whole of the worlds
time scale.
Didn't the swiss try to take it a few years ago with that idea that a unit
of time lasts roughly 4 mins'. And there there were only 10 hours in the
day, or something like that.

Regards

Colin Dawson
www.cjdawson.com

p.s. In case you didn't realise, I too think that storing a datetime as a
floating point as currently happens is not the best idea, but it's the best
solution at present. I'd love to see something that is accurate enough for
everyone, better still, I'd love to see the leap seconds being predicted so
that it can be placed into the date algorithms, then there'd be no need to
have these issues at all.

>
> ======
>
> One must distinguish between various ideas, largely US, for changing
> date/time. Some concern leap second effects, some leap day effects (for
> which the most intelligent move at present would be to replace the two
> rules that Pope Gregory XIII added with a single 128-year rule, first
> effective in 2048.
>
> Of more immediate importance : they may well be changing their Summer
> Time rules. This should provide the rest of us with a degree of
> amusement, assuming that they don't manage to update all relevant
> software and parameters in time.
>
> It would be useful to have a concise but exact and authoritative
> statement of the US DST situation (the web pages of their media are
> bloated and dumbed-down).
>
> --
> © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00
> MIME. ©
> Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links,
> acronyms
> PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see
> 00index.htm
> Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm
> etc.


.

Relevant Pages

  • Re: Why the US wants to end link between time and sun
    ... school at 3:30 pm in the middle of winter and it was already getting dark. ... Making a leap hour won't solver the problems for programmers either. ... for flight instrumentation there should be a method for detecting ...
    (uk.sci.astronomy)
  • Re: Why the US wants to end link between time and sun
    ... >Making a leap hour won't solver the problems for programmers either. ... 60 yet the fraction is binary. ... One should never refer to Julian dates without explanation (the Julian ...
    (uk.sci.astronomy)
  • Re: Why the US wants to end link between time and sun
    ... >> Making a leap hour won't solver the problems for programmers either. ... and a fraction) ... them other than hard coding the leap second into the algorythm, ...
    (uk.sci.astronomy)
  • Re: Why the US wants to end link between time and sun
    ... > Making a leap hour won't solver the problems for programmers ... > a fraction) ... This presents the problem that adding a leap ... be introduced if we want to have fields representing ...
    (uk.sci.astronomy)
  • Re: DAY Number in an Year
    ... >> FUNCTION juldate ... >> the starting point or to change Gregorian dates to Julian. ... For a one-to-one correspondence with calendar dates, ... the leap day at the end of Feb. was at the end ...
    (comp.lang.fortran)