How to determine timezone?

[beelzerob]

So, I finally calculated that for some reason, the "live" tv time I was getting from the GetAiringStartTime() was 7 hours different (ahead) from what my clock on the wall was saying. As it turns out, our timezone is -7 from GMT, so I figured out that the time being returned from those API calls are in GMT. So if I want my local time, I have to figure out how many hours to subtract.

I found the api calls for GetTimeZone, SetTimeZone, GetAllTimeZones.....but they're all strings. I had expected just a simple integer number of hours that the local timezone was different from GMT.

So, I try GetTimeZone, and it's "MST, Mountain Standard Time, " etc. stuff. Pretty much what I expected.

However, I do NOT want to try and match a string to find the timezone. That's a lot of work, a lot of room for error, and if I DON'T do it, then it really limits the portability of my code.

Isn't there some EASIER way to determine the hour offset from GMT that is localtime.

Thanks

[nielm]

GetAiringStartTime() (like Time() and other Studio Time functions) always return time in Millis (milliseconds since 1/1/1970 00:00:00 UTC)...

So if I want my local time...

PrintTimeXXX(), PrintDateXXX() and DateFormat() should do the conversion to the correct local time zone based on the system TZ.

GetTimeZone()+", "+Time()+", "+DateFormat("dd MMMM, yyyy  HH:mm:ss:SSS zzz", Time())
gives:
CEST Central European Time (Europe/Paris), 
1157364586444, 
04 September, 2006  12:09:46:444 CEST

, and using an online unix date converter 1157364586== Mon, 04 Sep 2006 10:09:46 GMT
So the UTC times are being correctly converted to the local time zone for display, there should be no need to manual perform TZ calculations...

(unless I misunderstood what you meant by 'if I want my local time')

[beelzerob]

Ok, I think I understand what you're saying.

The GetAiringStartTime() and similar functions returns time in reference to UTC (so, +0 GMT). What I was looking for was a Sage API call to return the hours offset that the local time is (for instance, I'm in GMT - 7 hours local time). What YOU'RE saying is that that should be a local system function, right? instead of having Sage try to handle the timezone difference, I should have the local operating system make the conversion, right?

That kind of makes sense to me. And there is probably a java function I can use to do that.

[nielm]

actually, I am saying that you should not need such a function...

If you want to see how far in the future/past an airing is:
Time()-GetAiringStartTime() will return the (zone independant) timediff in Millis, which can then be sensibly formatted with PrintDuration()

If you want to display the localtime, then there are functions for it.

If you can explain why you need the TZ offset, then that would be helpful!

(PS: just so that I am not being unhelpful:
DateFormat("ZZZZ",0)
will return a string with TZ offset in RFC-822 format, ie "+-HHMM")

[beelzerob]

Ok, I'm just not getting it...let me explain what I'm doing more fully:

I use GetAiringStartTime() to get a time in millis from Jan 1 1970. I convert it to seconds, and so now I have a really big long number.

I send that number over TCP through the java server to my CQC driver, which is connected to that socket. So, my CQC driver takes that number in.

The CQC software has it's own time functions, and one of them allows you to SetTime(time), so I set the time using the passed in time value I got from Sage. Once that time is set, I can get the hours, mins, seconds, month, year, etc from that time. The CQC time functions are also based on the Jan 1 1970 thing.

However, when I converted the starttime over, I noticed that it did not correspond to the start time listed in Sage for when the recording took place. For instance, in Sage, it says the show was recorded on Saturday at 10:35pm, but when I had sent it to CQC and converted it and output it, it came up as Sunday 5:35 am. That's when I figured out the 7 hour time difference. So, the CQC stuff is correctly converting the passed in time from UTC time to hours, mins, secs, day, month, year, etc.....but what I'm getting out of Sage is the time in GMT + 0.

I want CQC to be able to show the same time that is listed in Sage for when the recording took place. So somewhere, either in java on the sage side, or in cqc, I need to be able to convert the GMT + 0 time to whatever the localtime is, and THEN it will match what Sage shows on the screen. So at this point, Sage on the screen shows me (GMT - 7) for when a show recorded, but when I use GetAiringStartTime(), I'm getting (GMT - 0).

I don't want to just simply subtract 7 hours from the time, because this driver is going to be used by people potentially around the world, so I need some handy way to convert from the GMT-0 time to what the local time is (and which is also the time Sage is showing on the screen).


Does that make more sense? Maybe you already understood it, I'm just having a little trouble. I just wanted to make sure we both understood the issue.

I looked at the Time() function you mentioned, but I'm not sure how that would help. For one thing, the Time() function doesn't mention if it's local or UTC time. Also, that returns the CURRENT time, and I'm not sure how I'd use that to determine how to convert the time for something I recorded weeks ago.

Hope I'm making more sense, or can understand better. Thank you very much for the help you're giving, nielm.

[GKusnick]

To put the values returned by GetAiringStartTime into a more useful form, try something like this:

java.util.Calendar cal = java.util.Calendar.getInstance();
cal.setTime(new Java.util.Date(GetAiringStartTime(airing)));

This gives you access to the individual fields like month, day, year, hour, timezone, etc.

But as Niel said, if you just want to compare time values or convert them to strings for display, you shouldn't need to go to those lengths.

Knowing more about what you're trying to do with these times might help us give you better advice.

[GKusnick]

Whoops, crossed in the mail.

Originally Posted by beelzerob

The CQC time functions are also based on the Jan 1 1970 thing.

The Jan 1 1970 thing is by definition GMT. I don't know much about CQC, but it sounds to me like there's maybe a bug in CQC (or in your CQC setup) that's causing it to misinterpret the dates you're giving it.

As to how to work around that, the Calendar functions I mentioned above might be useful there.

[beelzerob]

Ok, I'm still not quite getting across my issue. I don't think it's a CQC issue, I think CQC is correctly converting the passed in time value, it's just the passed in time value doesn't represent what I want.

So here's an example.

I record MASH. Sage shows (in the Recorded Shows section) that it was recorded on Saturday, Aug 19, 2006 at 10:35 pm.

I use the api to call GetAiringStartTime() on that recorded file. It returns to me a huge number, which is the millisecs of time since Jan 1, 1970. That number represents the day, date, and time that the recording started. I convert it to seconds to convenience (divide by 1000).

I then pass that number to the CQC side because I want to display the actual start time. I also have functions for showing show duration, time elapsed, etc...but I want to show the actual day/time the show started and stopped. The CQC side also has functions for converting a UTC time to a more friendly format of hours, mins, months, days, years, etc.

When I pass in the number, it converts it, and it spits out Sunday, Aug 20, 5:35am.

So, the number I end up with is 7 hours later than the time that Sage shows in the Recorded Shows tab.

My time zone is GMT - 7.....so it seems to me that GetAiringStartTime() is passing me the UTC time that the show started. I want the time that Sage shows in the Recorded Shows menu, which appears to be the LOCAL time that the show recorded.

I have found some java functions that return a raw offset from UTC to the current timezone.....I think that's what I'm looking for. That way, I can take the sage api returned value for GetAiringStartTime() which is in UTC, and add the raw offset (which will presumably be -7 hours for me...but it would also return a correct system value for anyone who uses this driver). That gives me a UTC-based time that I can now pass to CQC, it will convert it to day/month/hours/mins that represent the local time the show was recorded, not the UTC time.

Does that help?

Am I doing something wrong? Doesn't GetAiringStartTime() return GMT + 0 time for all of you, and if so, isn't that a different time than what you'd expect unless you actually live in GMT + 0 timezone??

[GKusnick]

Originally Posted by beelzerob

...which is the millisecs of time since Jan 1, 1970.

Just to be clear: it's the millisecs of time since Jan 1, 1970 GMT. The definition of that particular representation of time is that it measures from an instant of time that everyone can agree on, regardless of which timezone they live in. That mutually agreed instant of time is Jan 1, 1970 0:00:00 GMT.

Any software that accepts times in that format must measure from that same instant, or confusion results. You say that CQC accepts UTC times. Fine, what you're getting from GetAiringStartTime is a UTC time. If you're not getting the local time string you want out of CQC, then it seems to me that either CQC is misconfigured somehow, or you're not calling the right time-to-string function in CQC, or CQC doesn't actually accept UTC after all. I don't know enough about CQC to suggest which one of those might be the case.

The fact that GetAiringStartTime returns a UTC is not a bug; it's by design. All modern time APIs work this way, by representings times internally as UTC, regardless of what time zone you live in, and doing the conversion to local time only when rendering as a string or converting to a structured calendar time representation. This is so that (for instance) files modified in different timezones can be directly compared to see which was modified last, in absolute time (not local clock time, which would be meaningless for cross-timezone comparison purposes).

So while it might be tempting to just take the result of GetAiringStartTime and do some arithmetic on it to convert it to local time, that's not an ideal solution because you'd basically be lying to the time APIs about what time format you're using (i.e. passing local times where UTCs are expected). It seems like it would be worthwhile to try to figure out why CQC isn't doing what you want with the UTCs you're giving it.

That's my take on it, anyway. Again, I don't know much about CQC so maybe I'm missing something.

[beelzerob]

Ooooooook.....I get it now.

I see exactly what you're saying.

And it makes sense....CQC IS expecting GMT time, as that's what it uses also, and it would be kind of working behind the scenes if I manipulated the time to account for the timezone, and then fed it that time. I understand why that's not desireable.

CQC does have some functions that relate to timezone offset, but I figured that Sage had some similar functions somewhere because Sage displays the shows in Recorded Shows in my local time.....so it's making that conversion SOMEWHERE.

I'll look more into CQC and see if there is some place that the local-time offset is applied, perhaps in some of the hour/min related output functions.

Ok, I feel I do understand it now. And I understand now why most people don't have to try and determine the raw offset for timezone....it happens automatically in the output conversion.

Thanks for the info on this guys. I'm sure neither CQC nor Sage are broken....I'm just not using them right.