Paul Eggert <eggert@CS.UCLA.EDU> wrote on Tue, 16 Aug 2005 at 17:09:17 -0700 in <873bp9e85u.fsf@penguin.cs.ucla.edu>:
[ I had originally sent a version of this on Tuesday morning, but it failed to go through because apparently lecserver.nci.nih.gov is still firewalled, and elsie works only because of an MX record. ]
lecserver now has an MX record, so I think this is all solved.
Can we wait until then and include that number?
I wouldn't wait. We can update the comment later.
Given how long its been, I suppose you're right. I was expecting it within a day of Arthur's patch, but it's been more than a week now.
p.s.: I keep wondering if its a good time to propose changing the default name of US timezones to US/Eastern -style rather than America/New_York, because our timezones are set based on national policy
Unfortunately that's not quite true. The daylight-saving rules are national policy, but whether to adopt daylight-saving is decided more locally.
Sure. But for the most part, when someone knows what time zone they're in, they know they're in US/Eastern, not "the same time zone as New York." Where a more specific entry is available, like Monticello, KY, (or US/East-Indiana) of course users should use that. But it doesn't seem to speak to the general case of whether US/Eastern should be prefered to America/New_York for people outside of New York, NY. Like Monticello, AR; Monticello, FL; Monticello, GA; Monticello, IA; Monticello, IL; Monticello, IN; Monticello, LA; Monticello, MN; Monticello, MO; Monticello, MS; Monticello, NY; Monticello, UT; and Monticello, WI. It certainly seems to make more sense from a user interface perspective.
We will continue to support names like US/Eastern indefinitely, but the location-based names are more accurate.
But only if you're in that location. Otherwise they're less accurate. My proposal isn't based on accuracy though -- I'm more concerned with usability... --jhawk