P
Paul Lutus
Michael said:
Yep, which makes us think it's somehow free.
Yep, which makes us think it's somehow free.
A
Andrew Thompson
Michael Borgwardt wrote:
Yep, which makes us think it's somehow free.
The fact that non-replenishable (in scales of
a human lifetime) petrol/gas generally sells
for less than the price of an equivalent
amount of milk does not help that any. :-/
P
P.Hill
Erwin said:
Apparently so, judging from the arguments that can erupt over such calculations.
In the interest of trying to avoid having to explain this yet again to another
person who thinks they know the answer and trying to point out that
( day1Milliseconds - day2Milliseconds ) / MILLISECONDS_PER_DAY is NOT the
correct answer for many values of day1 and day2 I suggest you, the
reader interested in this problem, see:
http://www.xmission.com/~goodhill/dates/deltaDates.html
If you have any suggestions for improvements to the article or code, please let
me know.
-Paul Hill
T
Thomas G. Marshall
P.Hill said:
Curious: On all machine, in all locales, is the progression of java
milliseconds guaranteed to be linear?
M
Michael Borgwardt
Thomas said:
What do you mean with "linear"?
T
Thomas G. Marshall
Michael Borgwardt said:
(?)
Are there any jump discontinuities or ramping up or ramping down to
accommodate changes in leap seconds, etc., for the odd locale? Or is this
always true:
java end millis - java start millis == real world end millis - real
world start millis
Given an arbitrary start and end, and an arbitrary locale.
P
Paul Lutus
Thomas said:
Mr. Hill's earlier argument is that there are things about calendars that no
existing class accomodates. This is an easy argument to make. But the fact
is that one can get self-consistent results easily from GregorianCalendar
objects from different locations, assuming the machines' clocks and time
zones are set correctly.
"Self-consistent" only means the results agree with each other, not that
they agree with someone's arbitrary choice of reference frame. For example,
did you know that the clocks on board the GPS satellites must be made to
run at a different rate (a difference of microseconds) than those on the
ground, for relativistic reasons?
The are any number of such special reference frames, but for everyday
purposes, you can subtract two millisecond values in Java and get something
useful and consistent.
M
Michael Borgwardt
Thomas said:
This really has nothing to do with Java and everything to do with how the
underlying operating system implements its clock in regard to
leap seconds, daylight savings switches, etc.
Usually, this will result in sudden leaps of clock time, e.g. when
the clock is adjusted by a Network Time Protocol client. Of course,
the same thing happens when a user adjusts the time manually.
Another notable fact is that common OS's clocks are coarser than
the millisecond precision assumed by java, so the time will appear
to progress in little jumps of about 10 milliseconds
A
Andrew Thompson
http://www.xmission.com/~goodhill/dates/deltadates.html
(URL's with upper case are a hassle..)
...ummm, and what's with the white background?
That is, so.. last millenium! ;-)
[ Good content, though.
]
C
Chris Uppal
Andrew said:
Agreed that they are a hassle (and I wish /I/ had never used any), but
invalidating an existing URL is surely worse.
-- chris
P
P.Hill
Paul said:
One old point:
The OP and the arguments about that code were about calculating differences of
days, not raw differences in milliseconds, second, minutes or hours
Now on to increasing millisecond sequences regardless of the whether you want
them for subtraction of days, hours, minutes or seconds.
Thomas Marshall asked:
In Java the VM relies on the underlying OS which relies on the hardware,
therefore even a VM running in a special frame would consistently return
whatever the hardware tells it. As Paul L. mentions we can ignore such odd
special reference frame cases, but the gotcha is the hardware/OS value.
We can ignore locales and timezones, since the millisecond value is **supposed**
to be GMT, again to the limit of the machine, so assuming the underlying
hardware counts up then:
Answer 0: Yes, the java.util.Date millisecond value will be an ever increasing
sequence.
You can run one of those little NTP synchronizers that keep you OS/hardware
clock sync'ed. For more information about Network Time Protocol see:
http://tycho.usno.navy.mil/ntp.html
"Typical accuracy achieved is in the range 1 - 30 ms continuous, and is highly
dependent on the symmetry and speed of the Internet path between client and
server. Best results are achieved using a combination of servers which are
closest to the client in a network sense."
So how could this effect a java millisecond values?
The value is apparently only good on your machine (not the NTP server which is
often better) to 30 ms. For example, one NTP request might want to set your
system clock ahead 20 ms, but then after the network is less busy, the next NTP
check comes up with a closer value and wants to set it back maybe 15 ms.
Answer 1: NO, the sequence is not guarenteed to be increasing, because
theoretically there could be jump backs in the millisecond value, since running
NTP could result in resetting your clock up or down by something in the range of
1 - 30 ms.
Since it is the resetting of your system clock downward by something akin to NTP
which is where the potential problem lies, you could have something that might
be even more noticable on a system which
a. drifts noticably forward over a longer period (that is it's seconds are too
short, so counts too fast)
b. runs NTP infrequently enough that this drift is noticable.
Answer 2: NO, there might be jump backs in the millisecond sequence if you have
a system clock which drifts ahead in time and NTP service run infrequently
enough to produce a noticable jump back.
The above are listed in increasing size of jump backs in time.
The above only apply when you create a new java.util.Date/java.util.Calendar
based on the current time. Many applications make up values for "midnight", "8
AM" "last Monday", "End of the Month" using calendar calculations disconnected
from the actual local time.
A few solutions to work around the NO scenerios are to:
1. Run NTP often enough to stay within a minute or so and be willing to work
with time instances which are slightly off and thus
-- pay the guy/girl whose hours you just calculated an extra 3ms, 0.3
minutes or even 3 minutes!
-- bill the user who connected to your system to whatever the clock said.
Because often no one is going to worry about fractions of seconds or even a
minute or two.
I'm sure you aren't going to get far with a cell phone company with a letter:
"To whom it may concern, It has come to my attention that according
to my calculations, your reconds for the remaining balance for my
cell phone has lost 12.52 seconds ... I would appreciate being given
a credit for your incorrect calculation" hahaha.
2. Run NTP often to keep within a few 10's of ms range, then round to an
application appropriate value.
-- if you are actually worried about 1/10ths and you can't suffer
being off by a second or a 1/10th now and then (see previous solution)
then whenever you create or us a millisecond time value from the
system clock, you could round it to the appropriate precision.
3. Run a machine directly connected to a radio synchronized atomic time value
(see http://www.boulder.nist.gov/timefreq/stations/wwvb.htm) or able to NTP over
a quiet network (same town or better late at night) to such a time reference to
keep to a much closer time value than the 30ms value.
Personally, I have always taken solution #1 -- being willing to accept being off
by a small amount of time. Many network applications are built with some
variation of solution #2. People who _really_ care usually take solution #3.
A much bigger and more application noticable problem are scenerios which we have
hinted at, but wanted to avoid, so haven't addressed in this thread. I list
some of those below.
Common Error 1: Non-synchronized clocks
A common error scenerio are clients and servers which don't run NTP, exchange
times which are off by an application noticable amount. I used to get this all
the time when checking in files between a machine in (North American) 'Mountain
Time' and machine in 'Central Time' not all of which were running NTP despite
some variation of solution #2 being part of the older/newer check used in the
application.
Common Error 2: Forgetting TZ or DLS offsets
Another common error scenerio is to miscalculate timezone offsets so report
inappropriate milliseconds since 1/1/1970 thus throwing an hour or more error
into the mess.
Common Error 3: Running one machine on a timezone other than local time.
A really obvious error is a machine which is set to run its OS clock on GMT, but
the machine is located somewhere else. For example, a user leaves the timezone
on GMT, then sets the clock to read correct local time -- let's say New York
time -- but since the machine is set to GMT, the VM runs on GMT, thus any
reported millisecond time is off by the current difference between New York and
GMT Time.
Summary
Java relies on the OS which relies on the hardware to deliver millisecond
timestamp values. If the OS can change the value down, for example through
running a NTP time synchronization client, the time values are not guaranteed
to be an ever increase sequence. This is charateristic of the underlying
machine not of a Java date (timestamp) value. In order to deal with this
potential problem you can use a combination of frequent enough NTP resets and
rounding of time value to an appropriate precision. More common errors are to
be off not by parts of minutes, but by hours due to timezone errors.
HTH,
-Paul
P
P.Hill
Chris said:
Now the URL is less than one day old, so I COULD change it.
But err, ah. Can you explain?
Is it just because Domain names are case insenstive, so hand typing
the complete URL might come up with a mis-match on a name.
If I go away from mixed case URLs, how
could I directly reference a mixed case Java source file?
-Paul
p.s. I'll give it a colored background!
G
Gordon Beaton
NTP never sets the clock backwards. Changes in that direction are
acheived by updating the system clock more slowly, so that essentially
time catches up with your machine.
From rfc1305:
"The effect is to slew the clock to a new value at a small, constant
rate, rather than incorporate the adjustment all at once, which
could cause the clock to be set backward."
In any system with NFS mounted filesystems, even a few seconds of
discrepency between hosts can cause irritating problems. For example,
"make" won't rebuild a project if the target already exists with a
newer timestamp than files it depends on, which can easily occur if
files are updated from different systems with unsynchronized clocks.
The NTP faq gives further examples; this is one I've run into a few
times.
/gordon
T
Thomas G. Marshall
Michael Borgwardt said:
Yep, ok.
The question is whether or not the time leap occurs at the millisecond level
as well.
I can imagine a system where the milliseconds are uniformly and ever
increasing, one after the other, and the time leaps are done by calculation.
I can also imagine a system where the time leaps are back channeled to the
millisecond "generator".
T
Thomas G. Marshall
P.Hill said:
I see why there are two answers.
So, without NTP (and other similar outside events) the ms clock is not only
monotonically increasing, it is perfectly linear.
With NTP, the ms clock is possibly non-monotonic, (and :. non-linear.)
T
Thomas G. Marshall
Thomas G. Marshall
as per Gordon Beaton's point, the ms clock is /always/ monotonically
increasing, and often non-linear.
....[rip]...
as per Gordon Beaton's point, the ms clock is /always/ monotonically
increasing, and often non-linear.
....[rip]...
P
P.Hill
Gordon said:
Cool! I didn't know that bit. Thanks for the input and the correction.
Is this possible on an Intel chip? Can you tell it to 'skip one'
or 'double up' a bunch of clock cycles, so the system
clock never sees a jump back of any size even a series
of very small ones?
I've run into that one myself many times, even to a server that I don't have
control over, when I am running NTP on a simple Windoze box.
-Paul
A
Andrew Thompson
This is a good thing, where practical..
...I would stick with exact case in that situation
(or perhaps more accurately, I *do* stick with that)
Cool.. So many colors to choose from!
C
Chris Uppal
P.Hill said:
Happy Birthday !
Yes. URLs are case-sensitive, but people are irritatingly inconsistent in
this. At least, it seems to be unsafe to expect people (even programmers) to
get the case right in "normal" mixed-case URLs.
Like, Andrew, I think I'd stick with CamelCase for these files -- after all if
a Java programmer doesn't know the rules then (let's be frank) who cares if
they get it wrong ? (And if they're /not/ Java programmers then why are they
reading your .java files ?)
-- chris
P
P.Hill
P.Hill said:
Hmm, I just found the quote you mentioned. It is in the section
7.1.2 Unix Clock Model
There does not seem to be any other mention of slewing in
the entire document outside of this specialized section.
Information on making sure your Windows system is running SNTP is availble from
no less than NIST Boulder (the folks who keep Atomic Time in the Western US)
at: http://www.boulder.nist.gov/timefreq/service/pdf/win2000xp.pdf
See section 5.
I still don't see any guarantees anywhere that time will never jump back,
but I'm encouraged by the quote Gordon mentioned.
thanks,
-Paul