Anyway to *SET* the date & time?

Benjamin Schollnick junkster at nospam.rochester.rr.com
Tue Oct 12 19:20:37 EDT 1999


On Wed, 6 Oct 1999 16:03:22, Jeff <jam at quark.emich.edu> wrote:

> my suggestion would be to implement the server in python, but leave the
> client side to existing code, and then you won't have to worry about how to
> do it.

Would be nice, but I haven't found anything that seems to match
the RFC in the client side.  Most of the NTP clients that I have found
"require" UDP implementation, and I've just written the TCPIP.  I 
haven't messed
around with figure out UDP implementations at this time.

> > Honestly though, I think it's a semi long term gap that probably should be
> > filled.  At least on a platform by platform basis.  After all STRPTIME
> > isn't supported everywhere, why should TIME or DATE (or whatever they get
> > called).

> in my opinion facilities to set the date and time in a cross platform manner
> would be a non-trivial excercise and a security violation of the machine. I
> wouldn't want the average university student to walk up to a win32 machine
> with pythonwin installed and be able to muck about with the date and time of
> a machine with the simplicity of a function call-- at the least, a 'trick'
> ought to be required (like using 'os.system' or a custom C extension) just
> to keep things from getting out of hand. 

And anyone under Windows NT can already do that by opening a "DOS
window", or "Run Program" Dialog and access DATE & TIME that way.

Honestly, just about every other programing language I can think
of has some manner to set the date & time.  This isn't a accusation
just a statement of fact.

> client software that uses the NTP protocol to set the date and time have
> already been written for win32 and various other platforms, and a rewrite of
> said clients in python would have limited value for the reasons we have been
> discussing for the last several days-- it's a tricky topic.

Most of the clients, as said above, seem to use UDP, and not straight 
TCPIP.

> the server side, on the other hand, is clean and elegant in python, and
> ought to perform quite well, especially if replaced with something like
> medusa as a server framework. 

I'm hoping to handle that next.... But I've been side tracked with 
other projects
at work, including a "proxy bouncer".

> in terms of filling a gap by implementing some sort of 'setclock' function
> in the core python library, rest assured that guido and the other
> maintainers have put many many many hours into these issues (python wasn't
> born yesterday), and if there was a clean way to do it, they probably would
> have done it by now.

Or just never thought about it.  After all, how many programs actually
use "SET" 
date & time functions??? Not many.

> have you made any other changes to the server code since you posted it?
> would you be willing to repost or put it up on a web page someplace so
> everyone can get the benefit of your experience?

I will in a bit, probably this next weekend, but I'm working on a few 
other projects
in the meantime....

		- Benjamin

================================
Please feel free to copy any and or
all of this sig.
A little something for spam bots:

root at localhost postmaster at localhost admin at localhost
abuse at localhost postmaster at 127.0.0.1

Chairman William Kennard: bkennard at fcc.gov 
Commissioner Susan Ness: sness at fcc.gov
Commissioner Harold Furchtgott-Roth: hfurchtg at fcc.gov
Commissioner Michael Powell: mpowell at fcc.gov
Commissioner Gloria Tristani: gtristan at fcc.gov
consumerline at ftc.gov
fccinfo at fcc.gov
ssegal at fcc.gov





More information about the Python-list mailing list