alterplay / aptimezones Goto Github PK

Returns CDT, but it should be EDT at GRR airport

When we pass "nil" as location for "timeZoneWithLocation", returned result presents time zone for "Africa/Abidjan" region.
I suppose assertion or local time zone result or nil result, in case of nil input should be there.

Mind including a sample that just loads them up into a table view or something?

When queried with the position of Delhi, APTimeZones returns "Asia/Kathmandu" (UTC + 5:45), the correct timezone should be "Asia/Kolkata" (UTC + 5:30).

when i Pass the coordinates of "Pakistan, Faisalabad" it always return me "Asia/Kabul" where as it should me "Asia/karachi" as you can check via google api:
Faisalabad Coordinates

Result:
{
"dstOffset" : 0,
"rawOffset" : 18000,
"status" : "OK",
"timeZoneId" : "Asia/Karachi",
"timeZoneName" : "Pakistan Standard Time"
}

Where as APTimeZone Returns: Aisa/Kabul (GMT +4:30) offset 16200 It is wrong

Can you suggest any solution to this or fix this bug in APTimezone.

On the latest tag (1.1), the method importDataBaseFromFile still attempts to load the timezonesDB.json from the mainBundle, which is the host application's bundle. The file isn't found there, but rather inside APTimeZones own Framework bundle. As a result, the following assertion fails and the app crashes in debug:

    NSAssert(jsonData.length != 0, @"timezonesDB.json not found in app bundle");

I don't quite understand how this would accurately return the timezone. Timezones are shapes defined by government organizations. Your database describes points. Your code will not function properly near timezone borders or in cases where there are actually holes in timezone shapes like in the US state of Indiana and in parts of Arizona.

Framework returns ET when it should be CT.

Tennessee has two timezones.

I've been giving APTimeZones a tryout. Along with the wrong TZ errors that others have reported for many US locations, I was running into a problem with a crash because of memory being released if I tried to look up more than one location. The problem seems to be that the timeZonesDB property in APTimeZones is not retained and was getting released between lookups.

In the importDataBaseFromFile method, the DB array is created using

NSArray *timeZones = [NSJSONSerialization JSONObjectWithData:jsonData
                                                    options:NSJSONReadingAllowFragments
                                                    error:&error];

I fixed the crashing problem by changing that to

NSArray *timeZones = [[NSJSONSerialization JSONObjectWithData:jsonData
                                                    options:NSJSONReadingAllowFragments
                                                    error:&error] retain];

Also, it looks to me like there is another potential memory bug in the APTimeZones class in the closesZoneInfoWithLocation method. Memory for a zoneLocation object is allocated every time through the loop,

    CLLocation *zoneLocation = [[CLLocation alloc] initWithLatitude:latitude longitude:longitude];

but is never released.

Pertaining to use with lat-long:

Doesn't produce correct results for my home location in the US (CST, Tulsa, OK) because "closest" timezone location (Vincennes, Indiana) is in another timezone (EST).

Needs some way to weight the results for latitude offset, or more entries in the table to minimize this issue. Timezones aren't tidy, but they are mostly a function of longitude.

Hello,

I don't know if it was me using it wrong, but the timezones returned for St.Louis, MO, USA and Dallas, TX, USA are inaccurate, they should both be in the Central Daylight Time, but APTimeZones returns Eastern Daylight Time.

Thanks!!! Nice work by the way!

Hey, How are you dealing with the change of timezones for daylight saving?

Thanks
Luke