converting a GMT timestamp into a ET one

[Jean-Luc Morin-Chesnel]

Dear all

I have a %tc timestamp GMT variable in Stata that I would like to convert into EST.
My timestamps look like : 9oct2015 12:00:00 and I dont care about leap seconds.

To do that, I basically have to substract 4 hours (sometimes 5).
Problem: I dont know how to do that.

Indeed, things seem to be more complicated than when one deals with daily %td dates (so that date+1=the next day).
I tried something like

gen double est_timestamp=dhms(dofc(timestamp)),hh(date)-4,(mm(date)),ss(date))

but this fails around midnight when its already tomorrow in europe ;-)

Any ideas? Many thanks!!

[Clyde Schechter]

Try this:

local 4hours = 1000*60*60*4 // # OF MILLISECONDS IN 4 HOURS
gen double est_timestamp = timestamp - `4hours'

The principle is simply that Stata datetime variables are just the number of elapsed milliseconds from midnight 1 Jan 1960.

That said, I don't know what the (sometimes 5) refers to. Does that have to do with daylight savings time not being synchronous in the Eastern US and GMT? If that's the issue, I don't know how to solve it without some elaborate routine that encodes the dates of daylight savings time switch over.

[Jean-Luc Morin-Chesnel]

ok it was that simple! thanks clyde!!

[Nick Cox]

GMT I know about. I have straddled the meridian at Greenwich! It changes smoothly; it's just a question of whether people in some given place are using it. It's changing from or to a different scale that causes a hiatus.

So, doesn't EST change smoothly too?

Either way, the central issue here is shifting by an additive constant: 4 hours would be 4 * 60 * 60 * 1000 milliseconds, which you should subtract from the clock time.

As you've said, subtracting hours and keeping the same day isn't the way to go.

[William Lisowski]

The difference between 4 and 5 hour offset is pertinent if the objective is to change GMT to local "Eastern Time" - either Eastern Standard Time (EST = GMT-5 hours) or Eastern Daylight Time (EDT = GMT-4 hours), depending on the precise time of the year. If a result in EST can be used year-round, subtracting 5 hours will always work. Of course, converting GMT to a combination of EST and EDT will cause some durations to be overstated by 1 hour in the spring and understated by 1 hour in the fall (including negative durations).

[Nick Cox]

William: That's my understanding too. Thanks for spelling it out.

I'll add that I don't think Stata has any inbuilt knowledge of when anywhere changes local time-keeping practice. You would need to provide that yourself. Clyde I think is saying the same.

[Roberto Ferrer]

A "shortcut" for 4 * 60 * 60 * 1000 is -msofhours(h)-, where h stands for hours. As already mentioned, the important thing to keep in mind is that datetime variables hold milliseconds since 01jan1960 00:00:00.000.

[Nick Cox]

Roberto is right. I prefer just to work it out on the fly rather than look up the function name. (Note that in a serious application, there would be some inefficiency in obliging Stata to do the multiplication for every observation; or indeed to evaluate the function ditto.)

[William Lisowski]

Where I wrote GMT, to reduce ambiguity I should have written UTC.

My understanding is that UK localities that have GMT as their local time zone switch to a "Daylight Saving Time" (called "British Summer Time" in the UK) during much of the year, and I have been involved in discussions where that confused things mightily. The timestamp in the original data, however, is almost certainly UTC, so there is no consideration of it being anything other than smoothly changing, as Nick pointed out. My concern, and the point of my post, was brought about by Clyde's wording "... daylight savings time not being synchronous in the Eastern US and GMT" (which I read as pointing out that the US switches back 1 week later than the UK, for example) which suggested concern that the GMT times were also subject to DST considerations.

My bottom line is that in converting from UTC to local time, you can either consistently convert to Standard Time, and by doing so facilitate comparison of two timestamps and calculation of elapsed times, or you can convert to a mix of Standard and Daylight Saving Times, making local time obvious but complicating comparisons and durations twice a year. My own vote would be to convert to Standard Time, or to both, using whichever is appropriate as needed.