From: Francis Cianfrocca [mailto:garbagecat10@gmail.com]
Sent: Friday, August 18, 2006 8:51 AM
To: ruby-talk ML
Subject: Re: Microsoft Timestamp (Active Directory)
> Berger, Daniel wrote:
> > Leave it to Microsoft to come up with something this convoluted:
<snip>
Check the NTP protocol. This sounds like the format used by
NTP servers.
Leave it to me not to do any research before mouthing off.
Regards,
Dan
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
路路路
-----Original Message-----
On 8/18/06, Clifford Heath <no@spam.please.net> wrote:
Heh. If it does turn out to be NTP, then the only reason I recognized
it is because I had to write an NTP client in C recently (the standard
ones have more security holes than DNS). I thought it was bizarre too.
路路路
On 8/18/06, Berger, Daniel <Daniel.Berger@qwest.com> wrote:
Leave it to me not to do any research before mouthing off.
Leave it to me not to do any research before mouthing off.
Heh. If it does turn out to be NTP, then the only reason I recognized
it is because I had to write an NTP client in C recently (the standard
ones have more security holes than DNS). I thought it was bizarre too.
I can see some value to it. A high-res time is a good idea
in general, and dates that far precede the epoch are good,
too. (Half the people on this list can't represent their
birthdates with a Time object.)
Going back to 1601, you could at least represent Shakespeare's
death date to sub-microsecond precision and who among us
has never longed for that? (Still can't represent his birthdate,
though, and da Vinci is Right Out.)
Cheers,
Hal
路路路
On 8/18/06, Berger, Daniel <Daniel.Berger@qwest.com> wrote:
I use an unsigned 64-bit count of 10-ns intervals
since the (non-existent) year 0 of the Gregorian
calendar. Since it's non-existent, I double up any
value in year zero as meaning "time only, no date"
up to one year duration.
The Windows SystemTime() API returns 100ns units,
and I might have done that instead to avoid the
multiplication by ten (multiplication and division
or 64-bit qtys can be pretty horrendous on Intel
machines), but I can still construct a new C++
"current time" object in 100ns on a P4, so that's
fast enough to use in calculating my timings, which
sometimes schedule things down below 1ms, which
is the resolution of Sleep().