What's the correct time-offset (GMT - X) for Eastern Time Zone?

[Guest wsxedcrfv]

I don't know if this is a network or internet topic (don't know where else to ask this).

I'm under the impression that your GMT offset is fixed (constant) all year for your given geographic location or time-zone, regardless if (or when) your time-zone implements DST, and as such, the correct GMT offset for the Eastern Time Zone is -0500 (-5 hours).

I'm seeing a lot of e-mail with the time-offset being -4 hours from people in the Eastern Time zone, and Date: header line of their messages, and all the intermediate handlers are using -0400 as the offset. So Outlook is showing me a sent-time that's 1 hour later (1 hour in the future) then they were actually sent.

So what's the correct GMT offset for systems in the Eastern Time Zone? Am I right that it should *always* be -5 hours?

Edit: When I bring up the Windows tzedit.exe on my system, I can edit the start and stop date for DST, and the time-bias for the DST period, but there is no option for changing the GMT offset during DST. In other words, in TZedit I can select my GMT offset for my zone, but it doesn't appear that I can ALSO select a GMT bias or offset during the DST period.

So this doesn't make sense.

If the correct time offset for the Eastern Time Zone is currently GMT - 4, then the windows tzedit doesn't allow for the appropriate change.

Tzedit interface allows the clock to be changed (biased) during the DST period - but has no setting that alters the GMT offset(?)

So I need to create two time-zone entries using tzedit: One where I specify GMT - 5, and one where I specify GMT - 4, and I need to manually change my system's time-zone setting to the appropriate selection on the dates when DST starts and ends?

My system knows that at 2 AM on the second sunday of march, that my clock is supposed to be turned back 1 hour. But how do I know *what it thinks* is the correct GMT offset to use during this DST period? By all accounts, it thinks it's still GMT - 5. Or do different versions of windows handle this differently?

Edited March 31, 2010 by wsxedcrfv

[submix8c]

World Time

The offset is "fixed" except when Daylite Time is applied (Spring Forward/Fall Back 1 hr). If you "undo" "Adjust for DST" and/or set your Time Zone to GMT and Synch yourself (e.g. "time.windows.com") you'll see something interesting...

Also note that pre-XP does not have an actual "official" DST "fix", but there is a thread (somewhere) pointing to "unofficial" fixes (maybe in the 9x "stickies").

Does this help?

Edited March 31, 2010 by submix8c

[Tripredacus]

This happens to us constantly, but we just ignore it. Our computers do not have access to the internet. We do a BIOS update and set the time, then in Windows we have it set to GMT -5 and the time is ALWAYS an hour off. I'm not really sure why this is, but they correct themselves once they connect to the time server.

[Guest wsxedcrfv]

As far as I know, Windows (perhaps any version of windows) is configured with a single GMT offset as defined by the Time Zone properties in the system's clock / calendar interface or setup window.

For the Eastern Time Zone (US / Canada) that offset is GMT - 5 hours.

The DST rules for that zone specifies that a bias of + 1 hour which starts the second sunday in march and end the first sunday in november.

But does that mean that those systems will alter their time-stamping systems such that they change both their clock-time (add 1 hour at 2 am) *AND* change their time-zone bias (from GMT -5 to GMT -4) ???

As far as I can tell, windows systems do not change their zone bias from -5 to -4.

The tzedit.exe program (which allows the DST rules to edited or modified) does not seem to allow for a change in the GMT bias. Windows systems that perform the DST time-change correctly don't seem to alter their GMT bias from -5 to -4.

I believe that any windows e-mail client or mail server that creates or handles SMTP messages will (or does) continue to time-stamp messages headers with GMT -05:00 instead of GMT -04:00. This causes an apparent 1-hour future time-shift of any message sent or created by those systems.

Am I right in this observation?

Does the Windows operating system change it's GMT offset in response to DST?

When an application program (e-mail client, SMTP server service, etc) requests the current date and time on a Windows system for the purpose of creating a time-stamp, does the OS report back a GMT offset of -5 or -4 during the DST period?

[cluberti]

As far as I know, Windows (perhaps any version of windows) is configured with a single GMT offset as defined by the Time Zone properties in the system's clock / calendar interface or setup window.

At least since Windows 2000, everything internally is done in GMT (UTC) and the offset of file times and the clock is simply a display issue - the OS inside is doing everything on UTC.

But does that mean that those systems will alter their time-stamping systems such that they change both their clock-time (add 1 hour at 2 am) *AND* change their time-zone bias (from GMT -5 to GMT -4) ???

A system that is configured in a time zone that experiences DST will change the clock display at 2AM on the requisite day and the internal bias for local time will update, either forward or back as necessary.

I believe that any windows e-mail client or mail server that creates or handles SMTP messages will (or does) continue to time-stamp messages headers with GMT -05:00 instead of GMT -04:00. This causes an apparent 1-hour future time-shift of any message sent or created by those systems.

That would be more a behavior of the app itself (and what APIs it uses, if any, to determine the correct UTC offset) rather than Windows - I'll explain further on.

When an application program (e-mail client, SMTP server service, etc) requests the current date and time on a Windows system for the purpose of creating a time-stamp, does the OS report back a GMT offset of -5 or -4 during the DST period?

That depends on what API was used to request system time. If, say, a C or C++ app was to call time, it would get the current offset from January 1, 1970, not an actual time. Hence it would have to make a determination what GMT offset the system was at, etc - it would not be given by time. In Win32, there is no API to give you all of the data you want, but you could create a SYSTEMTIME structure, get SystemTimeToFileTime, copy FILETIME to a large INT, and then do arithmetic on the value (not pretty). There are other combinations of APIs that can be used in tandem to determine the system (UTC) time, the current time zone and time zone offset, and then determine whether you're in DST or not:

GetSystemTime - current UTC time

GetLocalTime - current local time

GetTimeZoneInformation (2003, XP, 2000) / GetDynamicTimeZoneInformation (Vista+) - gets the current time zone info, including whether or not DST is currently in effect

You would then use the data you returned to determine what the actual GMT time is, etc. As you can see, it's not something you just "get" when you're running on Windows as an app - you have to query it (properly) and manipulate the data you get back to determine this sort of data. Any shortcuts in getting the info, or failing to deal with the data returned by GetTimeZoneInformation to determine if you're biased due to DST, etc, will result in the wrong time used in an app. It's not hard to do this, but it's not easy either, and I too have seen any number of apps that screw it up.