- Test - lists.nanog.org

Netscape JavaScript getYear() problem? Also bad JavaScript on CNN.
by Will Pierce 02 Jan '00

02 Jan '00

Hello folks, I discovered to my utter delight that my lights stayed on during the roll-over. However, after poking around looking for the year 1900, I only found one issue. It appears that the javascript function "getYear" in the Date class is inconsistent between Java implementations. This happens when getYear() is called with no arguments, in other words, when getYear() is queried for the current year. I am not terribly JavaScript "Clue-Compliant" so if I make any blunders in this post, please set me back on track. Specifically, I get the following test results: Platform Browser Version getYear() returns -------- -------- ----------- ----------------- Win98 Netscape 4.61 100 Win98 Netscape 4.7 100 Win98 MSIE 5.00.2919 2000 You can look at what your browser's JavaScript interpreter returns for getYear() by loading: http://www.dreamscape.com/willp/y2k.html Apparently, Netscape 4.61/4.7 is not properly reporting the year in a getYear() call. >From what I've read on the net (which is NOT extensive and I'm in no way shape or form a java guru)- the getYear() function should return a 2 digit date up to and including the year 1999. However, in the year 2000 and beyond, getYear() should return a 4-digit date. Now, whoever thought up this getYear() function behavior should be shot, IMNSHO. I saw this when my "CNN Ticker window" in MSIE5 indicated that the current year was 2300. The CNN JavaScript assumes the getYear() function returns the # of years since 1900. Caveat: I have not tried looking at the return values of getYear() in JavaScript on anything other than my own home computer. It is possible (though unlikely I hope) that what I've seen is due to a strange problem with -just- my computer and its mangled DLL files under Windows 98. I would appreciate any confirmation of this strange behavior of getYear() under Netscape and/or any help in understanding this problem. If someone could confirm that they too see the year 3900 on the CNN "ticker bar" and that these results -are- in fact problems, I would really appreciate the feedback! The risk: Any web sites that use the getYear() function will need to accomodate various return values of getYear() and properly distinguish the bizarre results that some browser versions will return. In the case of sites that only use getYear() to *display* the date for the edification of the user, this won't have any operational effects. However, for sites that use date processing in a mission critical situation, there may be some problems. While I have strong hopes that no one would use client-side JavaScript in a mission-critical application, there is still the possibility that this will be a problem on some websites. For most sites affected by this, it will only cause embarassment. Random List of Affected Sites (found so far): CNN http://www.cnn.com/ The CNN "ticker" toolbar (downloadable at: http://www.cnn.com/browsers/explorer.bar/ ) indicates to me that the date is 3900, because their javascript function "ShowDate" adds 1900 to the result of getYear(). (MSIE5.00.2919.6307 on Win98) The date is only used for display purposes (as far as I can tell). Computer Technology Associates http://www.ctai.com/ The date displayed on their homepage indicates "January 1, 192000" under MSIE 5 on Windows 98. Their JavaScript assumes that it is always the 1900's and that getYear() always returns the last two digits of the year. The date is only used for display purposes. Rocky Mountaineer Tours http://www.rkymtnrail.com/ Same problem as for CTAI above. The date is only used for display purposes. JJournal Jeep Owners Resource http://www.jjournal.net/ Same problem as CTAI and Rocky Mountaineer Tours. The date is only used for display purposes. PegasoWeb Web Site Promotion http://www.pegasoweb.com/ Again, year is shown as 192000. The date is used only for display purposes. Web Medicine http://www.webmed.com/ The "last date modified" on this site indicates that the site was last updated on January 1, 3900. Apparently the date is only used for indicating to the visitor that the website is modified daily. Sport/Utility Vehicle Owners Resources http://www.suv.com/ Displays current date as year 192000. Date only used for display purposes. World Trade Center Institute http://www.wtci.org/frmain.htm Displays current date as year 192000. Date only used for display purposes. Inland Empire Online http://www.inlandempireonline.com/business/index.shtml Displays current date as year 192000. Date only used for display purposes. Resources related to this: Overcoming Different Year Conventions - Doc JavaScript http://www.webreference.com/js/pharmacy/article1/overcome.html Y2K JavaScripts http://server9.hypermart.net/ucprogramming/javascript/article1.html JS Year 2000 Very Basic Test Page http://www.nikwilliams.co.uk/jsdate01.html Java City 2000 - Year 2000 Fix http://www.jc2k.com/y2k.html JSBible Calendar Scripts and Y2K http://www.dannyg.com/calendarY2K.html -- Will Pierce Systems Programmer Nuts & Bolts Interactive, Inc. willp(a)nbinteractive.com P.S. If someone could confirm this behavior as being due to 1. differences in the implementation of the getYear() javascript function, and 2. poorly coded JavaScripts, I would be very grateful for the confirmation. I am no JavaScript programmer by any means, so this whole post could be way off base. I am only posting it so that some more experienced Java guru can either correct my mistakes or confirm and expand on what I'm seeing. Flames to /dev/null pls.

3 3

Re: mail does bounce (was: Customers down?)
by Sean Donelan 02 Jan '00

02 Jan '00

On Sat, 01 January 2000, "Steven J. Sobol" wrote: > What I was referring to was a situation where the domain does exist in the > root nameservers but the authoritative nameservers are unavailable. So .COM exists in the root servers? How do you decide to treat second level domains (i.e. donelan.com) versus third level domains (i.e. www.donelan.com) versus third level domains under country code domains.

2 1

Re: mail does bounce (was: Customers down?)
by Sean Donelan 02 Jan '00

02 Jan '00

On Sat, 01 January 2000, Jim Duncan wrote: > I recommend you not use three-digit RFCs as authoritative references. > I agree with your line of reasoning, but current arguments should be > supported by current observations and decisions, as documented by current > standards. I see a lot of crap on the net that's crap fundamentally > because its development was based on a three-digit RFC. :-( Whether or not you use three-digit RFCs as authoritative references, other developers do, so you should expect to deal with such behaivor. Too many people think the motto be conservative in what you send and liberal in what you receive only applies to the other guy. He should never send something I don't expect, and should accept anything I decide to send. > The human element causes many problems, and yet it is the ultimate > solution for all of them. Rather than strive solely to make things > perfect, try to make things as close to perfect as possible *and* put some > thought into what you will do when things fail. Assume that "calling the > human element into play" is a part of making things perfect, whether > you're dealing with failure of timely delivery of a message to the > intended recipient or failure of network connectivity to fail over > gracefully to another path. The question is how long do you let things wallow in a state of computerized uncertainity before you call the human. Things fail, and sometimes people create situations which make the failures even worse. Do you immediately inform the human, try a few times and then inform the human, keep trying until the human notices its not working. Different people make different choices. If a mailer wants to queue mail on a DNS server failure, that is acceptable. But you shouldn't expect or depend on that behaivor. If you disconnect all your name servers from the network; some applications can, and therefor you should expect they will, treat it as a permanent error. Whether you think its the fault of the human who wrote the application, or the human who put all the name servers on the same subnet; it shows problems are rarely due to a single mistake. Rather a combination of decisions, which may have appeared justified alone, when taken together cause trouble. Its like the backhoe problem. There would be no affect on customers if either a) carriers provisioned sufficient alternate capacity OR b) a backhoe didn't cut the fiber. Its the combination of insufficient diverse capacity AND a backhoe attack which causes the problem for the customer. Unfortunately, the first instinct is to blame the other guy. So telco's blame the backhoes; and the excavators blame the telco's.

1 0

Traffic statistics from major ISPs
by Sean Donelan 02 Jan '00

02 Jan '00

In the voice world, AT&T, SBC, Bell Atlantic and others have released traffic figures about how many voice calls they handled around New Year's. I have not seen similar data from any major ISPs about traffic volume around New Year's. I know about third-party sites such as Keynote, and MIDS; but they don't measure traffic volume. I'm looking for basic data such as ANS used to publish for the NSFNET. The closest I've found is Abovenet's MRTG pages, but it is spread out over different links and its hard to aggregate the numbers without double counting, or undercounting. I know several major ISPs collect the data internally, but haven't released it like the voice side of the house.

2 1

RE: mail does bounce (was: Customers down?)
by Sean Donelan 02 Jan '00

02 Jan '00

On Sat, 01 January 2000, "Roeland M.J. Meyer" wrote: > > I agree with Greg Woods - if a domain is authoritatively non-existent, > > I'd expect a sane mailer to bounce the message. > > I'm glad that you don't write code, especially sendmail code. Trade-offs. Would you rather be notified immediately if you mistype an address, or wait four days before getting an undeliverable bounce. If the name exists, but the mail host is unreachable try the next MX record or if no more alternates, queue the mail. If the name does not exist, return mail to sender. If you can't figure out whether the name exists or not, do what? The RFCs just say a mailer is expected to do something "reasonable" in reponse to a domain server error. But RFC 974 doesn't specify what. An otherwise compliant mailer can queue the mail or bounce it, and still be considered compliant. If a site wants to avoid this unspecified behaivor, a wise site would try to assure availability of their DNS servers perhaps by using network diversity so a single failure won't take down all its servers. I remember setting up a connection last year with a major unnamed provider, and pointed out a similar issue. The other provider replied they had an extremely reliable network, and there will never be any problem with their DNS servers. Less than a month later, the extremely reliable network barfed, with the expected consequences.

1 0

Re: Well, MOST places got it right....
by Peter Murray 02 Jan '00

02 Jan '00

--On Sat, Jan 1, 2000 12:32 PM -0500 David Lesher <wb8foz(a)nrk.com> wrote: > http://www.cwru.edu We've been planning this for months: finding an "old fashion" font, scanning pictures from the university's archives and yearbooks, etc. The response that we've gotten to our webmaster account so far has been priceless. "Share and enjoy!" Peter -- Peter Murray, Library Systems Manager pem(a)po.cwru.edu Digital Media Services http://www.cwru.edu/home/pem.html Case Western Reserve University, Cleveland, Ohio W:216-368-8834

1 0

Y2K Funny
by Tim Wolfe 02 Jan '00

02 Jan '00

Well I'm sure I'm not the only one who heard this but NBC news just reported a story that the USNO website listed the date as 01 Jan 19100. So much for the most accurate clock in the world, heh. -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim(a)clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * --------------------------------------------------

4 3

Re: Customers down?
by Sean Donelan 01 Jan '00

01 Jan '00

On Fri, 31 December 1999, jlewis(a)lewis.org wrote: > I guess our customers aren't that silly. I did notice some big sites down > though. I tried to check a price with Tech Data earlier this evening and > found that www.techdata.com didn't exist. Traceroute to their > nameserver(s) > > techdata.com. 2D IN NS NS1.techdata.com. > techdata.com. 2D IN NS NS2.techdata.com. > NS1.techdata.com. 2D IN A 169.153.202.40 > NS2.techdata.com. 2D IN A 169.153.202.41 > > ends in a CW routing loop suggesting TD shut off their connection for the > evening. Putting your only name servers on the same subnet (unless Tech Data has VERY small subnets) isn't very smart no matter what day it is. Too many things can take down your one network. Instead of queueing mail, many mail programs will generate permanent errors and immediate bounces. Gun, Foot, Self.

5 4

Y2K
by Paul Ferguson 01 Jan '00

01 Jan '00

Well, here's to a major non-event. Cheers. Thank goodness. I chalk it up to a lot of hard work over the course of the past 5 years by a lot of people (some of coming very recently), and a smidgeon (well, maybe more than a smidgeon) of media hype. Again. In any event, let's hope everyone's Y2K is no more eventful than the last year. plop, - paul

4 4

Re: Curious thing in a Cisco router
by Sean Donelan 01 Jan '00

01 Jan '00

At 10:17 PM -0200 12/31/99, Rubens Kuhl Jr. wrote: >While monitoring GMT Y2K progression on a Cisco router, something curious >showed up: [...] >Notice the dot before the time; it was not appearing before, and even on the >first sample after GMT Y2K-rollover (local time is GMT -0200). It now shows >up on every 'show clock'. This doesn't seem to be a problem with cisco, but if you are synchronizing to certain NTP servers (i.e. usno or nist) they currently have reachability problems. So your cisco reports a "." that your ntp is unsynchronized. I haven't found out if the government networks are deliberately throttling traffic or if the links to the time servers are just congested. I have no idea why it started at almost exactly midnight UTC.

2 1