Why can't I convert a time zone abbreviation into a time zone?

Raymond Chen

Public Service Announcement
Daylight Savings Time begins this weekend in most parts of the United States.

Suppose you have a string of the form "Thu Mar 27 03:46:20 CST 2003". How can you parse this into something your program can manipulate, like say a SYSTEMTIME or a FILETIME?

Basically, you can’t in the general case. The time zone abbreviation CST is ambiguous. It could mean U.S./Canada Central Standard Time, Australian Central Standard Time, China Standard Time, or Cuba Summer Time. There may be other possibilities as well. Without any other context, the time zone abbreviation CST could mean any of those time zones. (This doesn’t stop people from asking for the feature anyway. Maybe they want fuzzy logic or psychic powers.) Note also that there is an international standard for representing dates and times in text form, including the time zone.

Okay, back to the original problem. In order to get a definite answer, you will need to restrict your domain to resolve the ambiguity. You might decide, for example, that you only care about the four continental United States time zones. Believe it or not, this is what JScript does!

var fso = new ActiveXObject("Scripting.FileSystemObject");
var f = fso.GetFolder("C:\\");
var fc = new Enumerator(f.files);
for (; !fc.atEnd(); fc.moveNext()) {
  WScript.echo("File: " + fc.item());
  WScript.echo("Date: " + fc.item().DateLastModified);
}

When I run this program via cscript testprogram.js, I get the following:

File: C:\AUTOEXEC.BAT
Date: Sun Jan 9 17:13:09 PST 2005
File: C:\boot.ini
Date: Tue Nov 22 11:53:48 PST 2005
File: C:\CONFIG.SYS
Date: Sun Jan 9 17:13:09 PST 2005
File: C:\hiberfil.sys
Date: Thu Dec 14 23:29:00 PST 2006
File: C:\IO.SYS
Date: Sun Jan 9 17:13:09 PST 2005
File: C:\MSDOS.SYS
Date: Sun Jan 9 17:13:09 PST 2005
File: C:\NTDETECT.COM
Date: Tue Aug 10 11:00:00 PDT 2004
File: C:\ntldr
Date: Tue Aug 10 11:00:00 PDT 2004
File: C:\pagefile.sys
Date: Thu Dec 14 23:28:59 PST 2006

Hey, look, that time zone got inserted. But if we make a tiny change to the way we print the date

var fso = new ActiveXObject("Scripting.FileSystemObject");
var f = fso.GetFolder("C:\\");
var fc = new Enumerator(f.files);
for (; !fc.atEnd(); fc.moveNext()) {
  WScript.echo("File: " + fc.item());
  WScript.echo("Date:", fc.item().DateLastModified);
}

the results are quite different:

File: C:\AUTOEXEC.BAT
Date: 1/9/2005 5:13:09 PM
File: C:\boot.ini
Date: 11/22/2005 11:53:48 AM
File: C:\CONFIG.SYS
Date: 1/9/2005 5:13:09 PM
File: C:\hiberfil.sys
Date: 12/14/2006 11:29:00 PM
File: C:\IO.SYS
Date: 1/9/2005 5:13:09 PM
File: C:\MSDOS.SYS
Date: 1/9/2005 5:13:09 PM
File: C:\NTDETECT.COM
Date: 8/10/2004 11:00:00 AM
File: C:\ntldr
Date: 8/10/2004 11:00:00 AM
File: C:\pagefile.sys
Date: 12/14/2006 11:28:59 PM

In this modified version, we’re print the time and date directly instead of using the JScript conversion. This time, the hard-coded U.S. English days of the week, months, and time zones aren’t present. (I haven’t checked whether OLE Automation follows local settings.)

(Reminder: Whether daylight saving time is a good idea has already been discussed, so please don’t waste everybody’s time by bringing it up again. Thanks.)

0 comments

Discussion is closed.

Feedback usabilla icon