I've been trying to work out some useful features relating to the time at which an event starts. Of course, since all event start-times are in UTC, whereas most users are not in that timezone, it might be useful to adjust to get the start-time *for the user's\r\n timezone*.
\r\nHowever, a quick investigation shows that in a very large number of cases, info in the "location" field (where supplied) seems to disagree wildly with the "timezone" field.
\r\nExample: In the training set there are in the order of 20 entries whose location field ends in "United Kingdom". Of those, 5 have an offset of 60 minutes, indicating UTC + 1 hour, which is believable (perhaps the data was taken when Daylight Savings was\r\n in effect). However, there are 10 entries with an offset of 420 minutes, i.e. UTC + 7 hours! (Timezone UTC+7 covers, for example, parts of Indonesia) .The other 5 or so entries cover a wide range of other offset values.
\r\nIn fact, a quick scan seems to indicate that timezone UTC+7hrs is rather over-represented compared to other offsets - although who knows, perhaps most of the training data relates to users from Indonesia...
\r\nI was wondering whether one of the organisers could give some indication of which set of information was more reliable - the "location" field, or the "offset" field. It seems to me that if the location is more reliable , it would be worthwhile investing\r\n some effort in parsing the location and trying to come up with corrections for unlikely timezone values; if the timezone offset is more reliable, however, then unless the timezone field is omitted it's probably best to mostly ignore the location field...
", "messages": [ { "id": "19892", "postDate": "01/31/2013 14:47:48", "content": "I've been trying to work out some useful features relating to the time at which an event starts. Of course, since all event start-times are in UTC, whereas most users are not in that timezone, it might be useful to adjust to get the start-time *for the user's\r\n timezone*.
\r\nHowever, a quick investigation shows that in a very large number of cases, info in the "location" field (where supplied) seems to disagree wildly with the "timezone" field.
\r\nExample: In the training set there are in the order of 20 entries whose location field ends in "United Kingdom". Of those, 5 have an offset of 60 minutes, indicating UTC + 1 hour, which is believable (perhaps the data was taken when Daylight Savings was\r\n in effect). However, there are 10 entries with an offset of 420 minutes, i.e. UTC + 7 hours! (Timezone UTC+7 covers, for example, parts of Indonesia) .The other 5 or so entries cover a wide range of other offset values.
\r\nIn fact, a quick scan seems to indicate that timezone UTC+7hrs is rather over-represented compared to other offsets - although who knows, perhaps most of the training data relates to users from Indonesia...
\r\nI was wondering whether one of the organisers could give some indication of which set of information was more reliable - the "location" field, or the "offset" field. It seems to me that if the location is more reliable , it would be worthwhile investing\r\n some effort in parsing the location and trying to come up with corrections for unlikely timezone values; if the timezone offset is more reliable, however, then unless the timezone field is omitted it's probably best to mostly ignore the location field...
", "rawMarkdown": "", "votes": null }, { "id": "19984", "postDate": "02/04/2013 00:17:14", "content": "Have you been able to make heads or tails out of the timezone/location issue? I know I tried to by doing string matching in between the location fields in both users and events, but most of the time, I can't do anything because one of the two fields is blank.\r\n Taking the longitude/latitude lines might work, that would require external data--which is ruled out because of the contest rules.
\r\n-Brett.
", "rawMarkdown": "", "votes": null }, { "id": "20133", "postDate": "02/07/2013 11:25:15", "content": "I have yet to make any progress on this - although this is at least partly because I've been concentrating on other parts of the data set.
", "rawMarkdown": "", "votes": null }, { "id": "20206", "postDate": "02/08/2013 22:32:44", "content": "Some set of users claim a location that's different from where they currently reside. The timezone is more indicative of their current location, e.g., they are travelling when they last used the product. The "location" is where they either claim to be from\r\n or they haven't kept their location up to date.
", "rawMarkdown": "", "votes": null }, { "id": "20389", "postDate": "02/12/2013 20:37:54", "content": "The rules exclude external data. I would like to be sure on this: are we allowed to use external data (like Yahoo Placemaker API) to convert location strings into coordinates?
\r\nWithout something like this, event coordinates would be useless.
", "rawMarkdown": "", "votes": null }, { "id": "20421", "postDate": "02/13/2013 14:12:17", "content": "Yes - that is not allowed per my knowledge
", "rawMarkdown": "", "votes": null }, { "id": "20464", "postDate": "02/14/2013 06:41:49", "content": "The rules for this competition disallow external data (which includes the Yahoo Placemaker API), so entries made to this competition should not use any external data.
\r\nHowever, if you find certain external data sources that would potentially be useful, feel free to evaluate them or comment on them (just don't use them to make an entry).
", "rawMarkdown": "", "votes": null } ], "comments": [ { "id": 19984, "author_name": "brett7", "author_url": "", "post_date": "02/04/2013 00:17:14", "content": "Have you been able to make heads or tails out of the timezone/location issue? I know I tried to by doing string matching in between the location fields in both users and events, but most of the time, I can't do anything because one of the two fields is blank.\r\n Taking the longitude/latitude lines might work, that would require external data--which is ruled out because of the contest rules.
\r\n-Brett.
", "votes": null, "replies": [] }, { "id": 20133, "author_name": "danielhutty", "author_url": "", "post_date": "02/07/2013 11:25:15", "content": "I have yet to make any progress on this - although this is at least partly because I've been concentrating on other parts of the data set.
", "votes": null, "replies": [] }, { "id": 20206, "author_name": "events4you", "author_url": "", "post_date": "02/08/2013 22:32:44", "content": "Some set of users claim a location that's different from where they currently reside. The timezone is more indicative of their current location, e.g., they are travelling when they last used the product. The "location" is where they either claim to be from\r\n or they haven't kept their location up to date.
", "votes": null, "replies": [] }, { "id": 20389, "author_name": "aolariu", "author_url": "", "post_date": "02/12/2013 20:37:54", "content": "The rules exclude external data. I would like to be sure on this: are we allowed to use external data (like Yahoo Placemaker API) to convert location strings into coordinates?
\r\nWithout something like this, event coordinates would be useless.
", "votes": null, "replies": [] }, { "id": 20421, "author_name": "rkirana", "author_url": "", "post_date": "02/13/2013 14:12:17", "content": "Yes - that is not allowed per my knowledge
", "votes": null, "replies": [] }, { "id": 20464, "author_name": "benhamner", "author_url": "", "post_date": "02/14/2013 06:41:49", "content": "The rules for this competition disallow external data (which includes the Yahoo Placemaker API), so entries made to this competition should not use any external data.
\r\nHowever, if you find certain external data sources that would potentially be useful, feel free to evaluate them or comment on them (just don't use them to make an entry).
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "19892": "", "19984": "", "20133": "", "20206": "", "20389": "", "20421": "", "20464": "" }, "source": "meta" }