Use the UTC+delta format and forget about summertime. We use it for the location, right.
------Origineel bericht------
Van: Bob Armstrong
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: SV: [HECnet] Hecnet map update
Verzonden: 10 januari 2012 03:07
I like the idea of expanding the info.txt .. time zone column
Fine by me. How is time zone expressed? Simply giving a numeric offset from GMT is problematic for places that observe daylight savings time - we'd have to update the file twice every year. Can we use something like PST8PDT??
Bob
No problem, bay area is fine.
------Origineel bericht------
Van: Bob Armstrong
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: RE: [HECnet] Hecnet map update
Verzonden: 10 januari 2012 01:45
When mapped on timezones the HECnet links are rather bizarre....
Some of you guys in the EU need to move to California...
Bob
On the other hand, using TZ as a way to place mahines
geographically basically sucks.
The location of each machine is already in the file, at least in the form of a city and country name. I'm sure there's some web service that would translate that into a lat/long.
Bob
I'll echo the sentiment of not wanting to sound like an AOL user....
With all of the recent, invigorating HECnet discussion, I am curious if anyone has a decent [approachable] resource for getting a TOPS-20 instance on the [HEC] net. I have a non-panda instance up (ARPAnet), and have a version of DECnet [apparently] installed, but no dice with HECnet connectivity. Worse case I guess I may use a captive account of sorts to gateway from WOPR:: to the 20x node via telnet.... but that just seems wrong in principle...
Joe
I'm not sure that is relevant. Dst changes don't affect which TZ you are in, only what time it is, and what you might call your TZ. If the purpose is only to give a rough idea, we could ignore dst. On the other hand, using TZ as a way to place mahines geographically basically sucks. Would be better with something like lat-long?
So maybe we really care about local time for machines as well, in which case dst is relevant..
Johnny
--
I like the idea of expanding the info.txt .. time zone column
Fine by me. How is time zone expressed? Simply giving a numeric offset from GMT is problematic for places that observe daylight savings time - we'd have to update the file twice every year. Can we use something like PST8PDT??
Bob
I like the idea of expanding the info.txt file as you are a prime example of a single area spanning multiple time zones. If you can specify a time zone column for each machine on your area there is no doubt. :)
-brian
On Jan 9, 2012, at 20:17, "Johnny Billquist" <bqt at softjar.se> wrote:
Meh. Nice idea perhaps, but not working. Oh well.
There are some possible tricks anyway.
You could create a file on the remote machine if allowed, and check the timestamp.
You can also check local time using remote datatrieve.
If you have a decnet-aware finger server, that might tell you.
And of course, if you can log in or run remote jobs, anything can be done.
But how about expanding the host.txt file (or whatever the name was)?
Johnny
--
Very cool map although you have area 52 in the wrong time zone. I'm east coast US with Steve.
-brian
On Jan 9, 2012, at 17:09, "H Vlems" <hvlems at zonnet.nl> wrote:
There is a new file called HECNETUPTMAP2.GIF
Two updates:
- area 42 was moved to UTC-8
- area 33 was misssing its connecting line.
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens Saku Set l Verzonden: maandag, januari 2012 22:59 Aan: hecnet at update.uu.se Onderwerp: Re: [HECnet] Hecnet map update
Copied to
http://vaxsys.mikromuseo.org/example/HECNETUTCMAP1.GIF
On Mon, Jan 9, 2012 at 23:55, H Vlems <hvlems at zonnet.nl> wrote:
On OZON you ll find a file called HECNETUTCMAP1.GIF
It puts nodes I had default decnet access to in UTC timezones.
The picture is considerably more weird than the earlier excel art .
OZON will remain up for the night so no hurry.
BTW some of you will notice a file called DATE.DAT or DATE.TEST in the default decnet directory.
I put it there to figure out the timestamp and thus compute the timezone. Assuming the system time is set correctly
Hans
Meh. Nice idea perhaps, but not working. Oh well.
There are some possible tricks anyway.
You could create a file on the remote machine if allowed, and check the timestamp.
You can also check local time using remote datatrieve.
If you have a decnet-aware finger server, that might tell you.
And of course, if you can log in or run remote jobs, anything can be done.
But how about expanding the host.txt file (or whatever the name was)?
Johnny
--
