A
Arne Vajhøj
Roedy said:
It has always worked reliable for me.
And if you read some of the other comments, then it is
apparently also working reliable for others.
Arne
It has always worked reliable for me.
And if you read some of the other comments, then it is
apparently also working reliable for others.
Arne
R
Roedy Green
For details of what I meant, see http://mindprod.com/jgloss/dst.html
R
Roedy Green
My radio-synched desk clock ticked over as advertised.
see http://mindprod.com/bgloss/radiosynchedclock.html
However Vista ticked over 2 hours. I will have a peek in BIOS. Perhaps
it did a kick over too.
R
Roedy Green
By that do you mean you cross checked with a radio synched clock, a
web atomic clock etc. or just that it behaved within a minute or two
to the time on the TV?
M
Martin Gregorie
How easy would it be to port the Jonathon Buzzard's shared memoryKarl said:
interface? The *NIX version relies on the shared memory functions in the
SVR4 Inter Process Communication package. C, not Java of course!
Has XP done away with the older Windows trick of copying the HW clock
registers into memory, updating them on the 18 ticks/second timed
interrupt and ignoring the HW clock until next reboot?
That was responsible for quite a lot of clock drift since, when Windows
got busy it tended to miss the timer ticks.
M
Martin Gregorie
GPS is useful as a time source as well as setting your location, whichRoedy said:
only happens once per OS install. It can provide a time standard that's
been cleared of propagation delays because the GPS receiver must have
such a cleaned time in order to work at all.
This is unlike all other common time sources such as radio broadcast
time (WWV, MSF, etc) and internet time sources, which must all be
corrected for propagation delays before they can be considered accurate.
Unless, of course, its a broadcast time source and you're fairly close
to the transmitter.
D
Dr J R Stockton
In comp.lang.java.programmer message <[email protected]
(a) I go by what he wrote, not what he might have meant.
(b) Newfoundland is a part of Canada.
(a) I go by what he wrote, not what he might have meant.
(b) Newfoundland is a part of Canada.
R
Roedy Green
java.lang.System.currentTimeMillis nominal resolution is measured in
ms. It seems to me I have seen resolution higher than 18 ticks a
second, so at least that must to looking at a higher resolution timer.
It seems to me I noticed something around the time of NT that lead me
to believe system time was being handled more accurately, but that was
a long time ago and I can't recall details.
I recall though dealing with ticks and lost ticks in DOS.
You could do an experiment to see if
java.lang.System.currentTimeMillis returns numbers in some non-1-ms
multiple.
System.nanotime is using the instruction counter clock.
K
Karl
Roedy Green said:
Most of the computers I have used to test my software remain accurate to the
second in comparison with a radio sync clock. They synchronize weekly with
NTP.
Windows uses the system timer hardware interrupt as a time base for time of
day functions. Since the system timer is a shared resource (on any system),
there are some cases where conflicts can arise. Operating systems have to be
aware if an application reprograms the timer, and notify all interrupt
handlers so that they can all can change their calculation constants. If the
clock is run at too high a resolution, interrupts can be missed, and time of
day accuracy suffers. Furthermore, the setting might be incompatible with
some handlers (usually too slow). If the timer is reprogrammed frequently,
some counts can fall through the cracks while the interrupt handlers
scramble to adapt. Some of these issues might be considered bugs, but some
are unavoidable. This bug
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500388) is probably due
to Java reprogramming the system timer.
In addition to programming issues, the accuracy of the hardware crystal time
base affects how much the computer time will drift. Any drift will cause a
discontinuity when it syncs with NTP. If the discontinuity is large enough,
in my application it can adversely affect time-critical wind speed
measurements. In that case, the work-around is to sync more frequently, so
the discontinuity is less. Or, do not sync automatically, and manually sync
the clock during system maintenance.
Here is an article that describes some timing considerations in Windows.
http://msdn2.microsoft.com/en-us/magazine/cc163996.aspx. Note that similar
considerations apply for other operating systems. In our case, we hope the
Java VM implementation can virtualize differences between platforms.
A
Arne Vajhøj
Roedy said:
Actually I am not sitting at that time and looking at the monitors ...
But it works fine the day after.
And if you consider how time is implemented in modern
computers then there is really no way it can go wrong.
Because time is not changed at all. The offset that is
applied when formatting the time for output or parsing the
time in input is changed.
And the offset must be dynamicly calculated based on the
not changed UTC time.
Arne
K
Karl
Arne Vajhøj said:Actually I am not sitting at that time and looking at the monitors ...
But it works fine the day after.
And if you consider how time is implemented in modern
computers then there is really no way it can go wrong.
Because time is not changed at all. The offset that is
applied when formatting the time for output or parsing the
time in input is changed.
And the offset must be dynamicly calculated based on the
not changed UTC time.
Yes, a single variable increasing monotonically, referenced to e.g., 1970,
01, 01, 00:00:00 UTC is the right way to do it. If a hardware interrupt
handler loses time incrementing a single variable every 10 msec, then we
have much bigger problems than time of day.
If the government would quit fiddling with DST all the time, we wouldn't
even need patches for time zone database localization.
R
Roedy Green
In modern operating systems including NT/W2K/XP/W2K3/Vista, after a
daylight saving change, you will notice the file dates on all your
files change by one hour.
This is as it should be!!
The actual dates are stored internally as GMT/UTC. The date displays
the file’s last-modified moment in time using the current time scheme,
not the time scheme in effect at the time the files were last
modified. So for example if your file were dated 2008-01-01T09:00PST,
that would be stored internally as 2008-01-01T17:00UTC, in other words
8 hours later, namely 17 hours after midnight on 2008-01-01 GMT/UTC.
In the spring, you change to DST. Then the difference between PDT and
GMT/UTC is only 7 hours, not 8. So that same instant in time would be
2008-01-01T10:00DST, even though DST was not in effect in January. In
the spring, Vista will display dates in DST, one hour later than
usual. In the fall, Vista will revert back to showing dates in PST,
one hour earlier. Don't modify the dates to compensate!
daylight saving change, you will notice the file dates on all your
files change by one hour.
This is as it should be!!
The actual dates are stored internally as GMT/UTC. The date displays
the file’s last-modified moment in time using the current time scheme,
not the time scheme in effect at the time the files were last
modified. So for example if your file were dated 2008-01-01T09:00PST,
that would be stored internally as 2008-01-01T17:00UTC, in other words
8 hours later, namely 17 hours after midnight on 2008-01-01 GMT/UTC.
In the spring, you change to DST. Then the difference between PDT and
GMT/UTC is only 7 hours, not 8. So that same instant in time would be
2008-01-01T10:00DST, even though DST was not in effect in January. In
the spring, Vista will display dates in DST, one hour later than
usual. In the fall, Vista will revert back to showing dates in PST,
one hour earlier. Don't modify the dates to compensate!
R
Roedy Green
You'd think that, but on my Vista Home Premium Acer machine the fool
thing jumped TWO hours ahead automatically.
G
Gordon Beaton
Even with a GPS there are factors to consider:
- At the NMEA standard bitrate of 4800 bps, it takes nearly 100ms just
to send a short sentence like ZDA (date and time).
- Some GPS units only send data at specific intervals, not necessarily
at the exact time the data was ready, and it gets worse if the unit
has a lot of data to send at a particular moment.
So when was that timestamp you just read from the device actually
taken?
/gordon
--
A
Andreas Leitgeb
No, it is not. (but it is still a progress to what theRoedy Green said:
old windows versions did)
Given any GMT-datetime and the base timezone, it can be
determined, whether that falls into the DST halfyear of
the base timezone.
If on a spring day, just before the switch I create a file
at twelve o'clock, then this time is converted to GMT for
current timezone, and the GMT-seconds since epoch are stored
with the file.
Then, a week later, I list the file, the GMT-time that
corresponded to twelve o'clock back then will be known
to belong to a non-DST time, and thus be displayed as such.
(though not on vista, as you described it)
It will assume the same timezone, but not the same DST.
At the time I write this, it is 1205133333 seconds since epoch
I'm in central europe, so this time is displayed as:
Mon Mar 10 08:15:33 CET 2008
in exactly 61 days (60*60*24*61 seconds), we will have already
DST. If I add this to abovementioned seconds, it will give me:
Sat May 10 09:15:33 CEST 2008
Yes, one hour later, of course, but with the extra "S", that
flags DST.
If today were already summer, and current time would display as
CEST, then displaying the date "1205133333 seconds since epoch"
would still display "Mon Mar 10 08:15:33 CET 2008".
This only happens on systems, that do not separate timezone from
DST. If your system doesn't know that "PDT" and "PST" are principially
the same then it will in summer display winter-timestamps one hour off
relative to what time it was back then.
Finally:
If I were to move to western europe today, and took my computer
with me, I would tell it my new timezone "WET", and *then* it would
display above timestamp (which could be the access time stored
with a file) as ..."07:15:33", which is correct.
While the computer knows about DST even for older dates, it surely
doesn't keep track about when I move to a different timezone.
My faint guess is, that future systems might do even that, once
wide distance mobility becomes a concern. But then, it really would
have to display the back-then timezone together with the time. E.g. it
would store the local timezone along with GMT-time for each file.
The GMT time is one important piece of information, but it might
also be interesting to know later, that some file was created in
australia at midnight, not in europe during normal office hours
A
Andreas Leitgeb
Andreas Leitgeb said:
Another sidenote: If I really didn't want the system
to automatically handle DST, I could set my timezone
to UTC-1 (for CET) or UTC-2 (for CEST), and it would
then show exactly those effects you described on vista
for PDT/PST.
R
Roedy Green
What sparked this was a report about timestamps changing on XP I
received in an email:
"When the time switches due to DST, the timestamps of all the files on
my PC change by one hour. I‘m reminded of this twice a year when I run
a backup script I have that calls xcopy. I’m using Windows XP Pro SP2.
I checked http://mindprod.com/jgloss/dst.html, but found no mention of
this problem. Is there some way of preventing this from happening?"
I also noticed on my own machine that Winzip seemed to think many
files that have not changed had changed, just after the DST flip on
Vista. I presume Winzip mindlessly works off displayed local time,
which would imply Vista had changed my file date displays.. I was not
on the lookout for this prior to the switch, so I don't have direct
evidence it did this. Perhaps I could figure it out my comparing
dates of backups, backups in zips etc
On what OSes is this cleverer file classifying behaviouryou described
exhibited?
The very idea of DST has always offended me, and horrified me once I
realised all the protential for disaster and error it creates. The way
we measure time should not be fiddled with. It is like dynamically
redefining the gallon to provide a gas tax/subsidy. We should simply
change business hours in the summer.
I had a friend, a railway buff, who called standard time "God's time"
and like the railways refused to acknowldge DST.
Given the global village we now like in, I think we should start
thinking about using UTC for any communication that could conceivably
span time zones.
A
Andrew Thompson
<pointed dig>
Which might be of relevance to North Americans
but is of little (specific) interest to people
who do not use the 'North American' ways of
calculating DST, such as ..well, 1 billion+ Chinese,
the Europeans, or anybody in the southern hemisphere.
(etcetera..)
<pointed dig *>
Admitedly, the original point of your question is
just as relevant to any community on the planet that
uses a pseudo-Julian (..Gregorian - I always get
them mixed up) calender. But..
Try thinking *outside* the hemisphere (or at least,
the north american part of it), Roedy. If anybody
can, you should be able to (I mention that knowing
you have had cause to visit the northern European
countries, at the very least)!
( * I just could not resist that
N
Nigel Wade
Roedy said:
Windows has managed to handle DST without any problems since, IIRC, 95. Timezone
setup is part of the installation procedure. If your PC is misconfigured with
the wrong timezone then you can easily fix it via the normal Windows GUIs.
Last I heard all versions of Windows still set the BIOS clock to wallclock time
not UTC, and messed with the BIOS clock for DST. This is hackery to me. Is that
not still the case?
L
Lew
Roedy said:
That doesn't make sense. When DST is not in effect, one shouldn't apply the
DST offset to the time. 2008-01-01T17:00:00Z will always correspond to
2008-01-01, 09:00 Pacific Time, because PDT does not apply on that date.
If Vista is incorrectly showing a Standard Time datetime as a Daylight Saving
Time datetime, then it's a bug.