A better way to obtain the time and synchronize clocks is to install a ntpdate server on the remote machine and an ntpdate client on the local machine - most clients offer an option to just obtain the remote time without modifying the local clock.

In either case the remote machine has to fulfill some constraints, so either it must do so already, or you need to have administrative access.

It will depend on what services are running on that remote computer, and whether you have access to them. There are all kinds of methods possible, but you'll have to have some cooperation from the remote site.

It might be much more efficient to talk to the admin(s) in charge of the remote box than for perlmonks to guess at a solution.

I am compelled to ask: Why do you even need this? I can think of some good reasons, I want to hear yours.

Sync'ing clocks in a network can be complex. Let's say my PC's clock is "too slow" vs "actual time". Ok, I can set my clock forward say 3 seconds and things will probably be fine.

Now what happens if my PC clock is "too fast" vs "actual time"? If I set my clock back 3 seconds, I will probably cause "time sequence errors" in log files, etc.

The way "I'm too fast" is handled, is by slowing my clock down until "actual time" catches up with me (ie maybe it takes me 61 actual clock seconds to tick off 60 of my clock seconds). That way all my files and log messages have the same time sequential order.

Anyway if this really is a network, your time will be the same as the others on the network. I remain curious as to your application.

I don't know what the OP has in mind, but we recently started working with some embedded system devices. Our device of choice has no clock battery at all, so every time you power up the clock must be reset. These devices are intended to be used remotely over the internet, so first thing it does is start openvpn to create a secure network to it. But without a reasonably close clock, openvpn won't even validate. So we use rdate just after the network starts to grab time off one of our servers.

Mind you we don't run Perl on our device, but I image there are plenty of real world situations where you just don't have a proper time to start with.

I think this is a fine example of an application that would need to get the approximate time to "get going". I don't know what the OP has in mind either. I do know that you have a very clear idea of what you are doing and why you are doing it. I remain curious as to the OP's application.

I wonder why you need the time and date of the machine?
Is it a Linux/Unix box or a windows-machine? Do you have supervisor rights on that machine?
A good network should have the same time ...

A good network should have the same time ...

And should (preferably) be stored as UTC if machines are located in multiple time zones. :-)