I'm having a little trouble understanding how the time field in /2/ open_events responses corresponds to the event time displayed on event pages. Here are five examples from a pull earlier today.
id time utc_offset Displayed time --------------------------------------------------------------------------- ---------- qqfjqyppbgc 16:00 -28800 16:00 41512512 07:30 +7200 17:30 39423092 18:30 -28800 18:30 39365812 10:30 0 18:30 qzrpgcyqdbmb 00:00 +36000 18:00
Can somebody please explain this, and how to calculate displayed time from time/utc_offset?
> I'm having a little trouble understanding how the time field in /2/ > open_events responses corresponds to the event time displayed on event > pages. Here are five examples from a pull earlier today.
> The easiest way to explain it is with code samples. What programming > language are you working in?
> Nathan
> On 12/01/2011 11:01 PM, Michael Reichner wrote:
> > Hello -
> > I'm having a little trouble understanding how the time field in /2/ > > open_events responses corresponds to the event time displayed on event > > pages. Here are five examples from a pull earlier today.
We've heard about some problems where the user's php environment could not work with 64 bit integers, causing it to overflow when converting from json. So that's the first thing to look out for, whether you have the full long int.
When you have that, you can divide it by 1000 to get seconds, then pass it to date($format, $timestamp) which gives you the actual time of the event, adjusted to your local time zone. If you look at your watch at that time, the event is starting wherever it is.
But if you're displaying dates and times to a user that you assume will be in the timezone of the event (as the Meetup site itself does), you want to adjust the time with the offset. Add the offset to the time event time before doing anything else to it.
> On Dec 2, 11:21 am, Nathan Hamblen<nath...@meetup.com> wrote: >> Hi Michael,
>> The easiest way to explain it is with code samples. What programming >> language are you working in?
>> Nathan
>> On 12/01/2011 11:01 PM, Michael Reichner wrote:
>>> Hello - >>> I'm having a little trouble understanding how the time field in /2/ >>> open_events responses corresponds to the event time displayed on event >>> pages. Here are five examples from a pull earlier today. >>> id time utc_offset Displayed time >>> --------------------------------------------------------------------------- ---------- >>> qqfjqyppbgc 16:00 -28800 16:00 >>> 41512512 07:30 +7200 17:30 >>> 39423092 18:30 -28800 18:30 >>> 39365812 10:30 0 18:30 >>> qzrpgcyqdbmb 00:00 +36000 18:00 >>> Can somebody please explain this, and how to calculate displayed time >>> from time/utc_offset? >>> Thanks!
> We've heard about some problems where the user's php environment could > not work with 64 bit integers, causing it to overflow when converting > from json. So that's the first thing to look out for, whether you have > the full long int.
> When you have that, you can divide it by 1000 to get seconds, then pass > it to date($format, $timestamp) which gives you the actual time of the > event, adjusted to your local time zone. If you look at your watch at > that time, the event is starting wherever it is.
> But if you're displaying dates and times to a user that you assume will > be in the timezone of the event (as the Meetup site itself does), you > want to adjust the time with the offset. Add the offset to the time > event time before doing anything else to it.
> (If date_default_timezone_set() is a global change then that code has > race conditions; there are probably better ways.)
> Sorry I don't know php well enough to provide a real code example, but I > hope this gets you off in the right direction.
> Nathan
> On 12/02/2011 12:25 PM, Michael Reichner wrote:
> > Thanks, Nathan.
> > I'm working in PHP
> > On Dec 2, 11:21 am, Nathan Hamblen<nath...@meetup.com> wrote: > >> Hi Michael,
> >> The easiest way to explain it is with code samples. What programming > >> language are you working in?
> >> Nathan
> >> On 12/01/2011 11:01 PM, Michael Reichner wrote:
> >>> Hello - > >>> I'm having a little trouble understanding how the time field in /2/ > >>> open_events responses corresponds to the event time displayed on event > >>> pages. Here are five examples from a pull earlier today. > >>> id time utc_offset Displayed time > >>> --------------------------------------------------------------------------- ---------- > >>> qqfjqyppbgc 16:00 -28800 16:00 > >>> 41512512 07:30 +7200 17:30 > >>> 39423092 18:30 -28800 18:30 > >>> 39365812 10:30 0 18:30 > >>> qzrpgcyqdbmb 00:00 +36000 18:00 > >>> Can somebody please explain this, and how to calculate displayed time > >>> from time/utc_offset? > >>> Thanks!
being a newbee to this java script world, it took me a while to understand this time millseconds! if you had added one line explanation what about this long number represent in your API page that would be great. "Time in milliseconds elapsed from midnight of January 1, 1970 expressed in UTC time zone" if you want to convert this time to local time add the utc_offset in milliseconds.
For example, if you are using C# assuming jo is your json object for the event, tMeetDate is the meetup time in local time zone. This is how you will convert long lTime = jo["time"]; long lOffsetTime = jo["utc_offset"]; lTime /= 1000; lOffsetTime /= 1000; DateTime tMeetDate = new DateTime(1970,1,1); tMeetDate = tMeetDate.AddSeconds(lTime); TimeSpan tsOffset = new TimeSpan(0, 0, (int)lOffsetTime); tMeetDate = tMeetDate.AddSeconds(lOffsetTime);
On Dec 2, 6:33 pm, Michael Reichner <coolg...@gmail.com> wrote:
> On Dec 2, 5:24 pm, Nathan Hamblen <nath...@meetup.com> wrote:
> > We've heard about some problems where the user's php environment could > > not work with 64 bit integers, causing it to overflow when converting > > from json. So that's the first thing to look out for, whether you have > > the full long int.
> > When you have that, you can divide it by 1000 to get seconds, then pass > > it to date($format, $timestamp) which gives you the actual time of the > > event, adjusted to your local time zone. If you look at your watch at > > that time, the event is starting wherever it is.
> > But if you're displaying dates and times to a user that you assume will > > be in the timezone of the event (as the Meetup site itself does), you > > want to adjust the time with the offset. Add the offset to the time > > event time before doing anything else to it.
> > (If date_default_timezone_set() is a global change then that code has > > race conditions; there are probably better ways.)
> > Sorry I don't know php well enough to provide a real code example, but I > > hope this gets you off in the right direction.
> > Nathan
> > On 12/02/2011 12:25 PM, Michael Reichner wrote:
> > > Thanks, Nathan.
> > > I'm working in PHP
> > > On Dec 2, 11:21 am, Nathan Hamblen<nath...@meetup.com> wrote: > > >> Hi Michael,
> > >> The easiest way to explain it is with code samples. What programming > > >> language are you working in?
> > >> Nathan
> > >> On 12/01/2011 11:01 PM, Michael Reichner wrote:
> > >>> Hello - > > >>> I'm having a little trouble understanding how the time field in /2/ > > >>> open_events responses corresponds to the event time displayed on event > > >>> pages. Here are five examples from a pull earlier today. > > >>> id time utc_offset Displayed time > > >>> --------------------------------------------------------------------------- ---------- > > >>> qqfjqyppbgc 16:00 -28800 16:00 > > >>> 41512512 07:30 +7200 17:30 > > >>> 39423092 18:30 -28800 18:30 > > >>> 39365812 10:30 0 18:30 > > >>> qzrpgcyqdbmb 00:00 +36000 18:00 > > >>> Can somebody please explain this, and how to calculate displayed time > > >>> from time/utc_offset? > > >>> Thanks!
If you are having problems dealing with the time due to the large size you can leave it as a string, strip off the last three characters to convert to seconds, then use it as an integer and you should be good to go. Using it as an integer before removing the milliseconds may cause problems in some environments.
On Mon, Dec 5, 2011 at 7:43 PM, Boloramji <r...@demandpoint.com> wrote:
> being a newbee to this java script world, it took me a while to
> understand this time millseconds!
> if you had added one line explanation what about this long number
> represent in your API page that would be great.
> "Time in milliseconds elapsed from midnight of January 1, 1970
> expressed in UTC time zone"
> if you want to convert this time to local time add the utc_offset in
> milliseconds.
> For example, if you are using C# assuming jo is your json object for
> the event, tMeetDate is the meetup time in local time zone. This is
> how you will convert
> long lTime = jo["time"];
> long lOffsetTime = jo["utc_offset"];
> lTime /= 1000;
> lOffsetTime /= 1000;
> DateTime tMeetDate = new DateTime(1970,1,1);
> tMeetDate = tMeetDate.AddSeconds(lTime);
> TimeSpan tsOffset = new TimeSpan(0, 0, (int)lOffsetTime);
> tMeetDate = tMeetDate.AddSeconds(lOffsetTime);
Most if not all dates returned by the api are represented in this format.
We usually list time with a description like "UTC creation time of the
event, in milliseconds since the epoch" The issue of dealing with a 64 bit
integer in platforms that only support 32 bit numbers comes up often enough
that we should have a special note in the docs. I'll look into adding this.
