GeoNames Forum

I've noticed a couple timezone errors.

Denver,CO is being returned with the America/North_Dakota/New_Salem which is an hour off from the America/Denver timezone.
(http://ws.geonames.org/get?geonameId=5419384&style=full)
Boulder, CO returns the America/Denver timezone.

Dallas,TX is being returned with the America/Indiana/Vincennes timezone which I think is actually Eastern time at this moment. Austin, TX and San Antonio,TX also exhibit this behavior.
(http://ws.geonames.org/get?geonameId=4684888&style=full)

Is there a way to correct those?

Thanks,
David

Has anyone else seen timezone issues? In addition to Denver,CO there are other cities like Colorado Springs,CO which should be assigned to MST (GMT-7) but instead have a CST (GMT-6) timezone. If I take the lat/long of Denver, CO and use the timezone lookup service it returns the expected MST timezone.

Thanks,
David

Hi David

There is something wrong with the timezone stored in the database. I will fix it with the values the timezone web service returns. It should be fixed this week.

Cheers

Marc

Hi David

I have checked all US places against the timezone polyons used for the timezone web service and updated all erroneous timezones.

Marc

Thanks! I got the latest database and everything looks good.

David

Hi everybody,

I'm trying to use the timezone web service. I queried the API for the time for New York City at 3:57pm EST. I got the following XML:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<geonames>
<timezone>
<countryCode>US</countryCode>
<countryName>United States</countryName>
<lat>40.67</lat>
<lng>-73.98</lng>
<timezoneId>America/New_York</timezoneId>
<dstOffset>-4.0</dstOffset>
<gmtOffset>-5.0</gmtOffset>

<rawOffset>-5.0</rawOffset>
<time>2008-02-26 21:57</time>
</timezone>
</geonames>

Should the dstOffset be -6.0? (21:57 - 6.0 = 15:57 = 3:57 pm)

Are there plans to include a line for the current local time?

Thanks!

Brandon

Hi Brandon

The 'time' element was brand new and it was supposed to contain the current local time. There was a bug and it displayed the time on the server instead.

Marc

I found a few more timezone mismatches:

1. El Paso, TX has its timezone set to Arizona time but it should be Mountain.
http://ws.geonames.org/get?geonameId=5520993&style=full
a lat/long lookup returns the correct timezone:
http://ws.geonames.org/timezone?lat=31.7587198&lng=-106.4869314&style=full

2. Ft. Walton Beach, FL has its timezone set to Eastern but it should be central.
http://ws.geonames.org/get?geonameId=4156042&style=full
lat/long is correct for this one also:
http://ws.geonames.org/timezone?lat=30.4057552&lng=-86.618842&style=full

We have fixed a bug in the timezone reverse geocoding, but not yet fixed the data in the dump.

marc

Thanks Marc. Should it be reflected in the results yet? The example links I gave aren't behaving any differently. A lookup of el paso by Id is returning a -7/-7 timezone which is incorrect. The lat/long lookup still returns the correct result (-7/-6).

David. There was a typo in my answer above (corrected now). It should have read 'we have NOT yet fixed it in the dump/db.

Marc

A search for Alice Springs gives a timezone of Australia/Broken_Hill (gmtOffset=10.5) rather than a zone with gmtOffset=9.5:
http://ws.geonames.org/search?name_equals=alice+springs&countryCode=AU&style=FULL

A timezone query gives the correct result:
http://ws.geonames.org/timezone?lat=-23.7&lng=133.8833333

A search for Unalaska gives a timezone of America/Adak (gmtOffset=-10.0) rather than a zone with gmtOffset=-9.0:
http://ws.geonames.org/search?name_equals=unalaska&style=FULL

A timezone query gives the same result:
http://ws.geonames.org/timezone?lat=53.8736111&lng=-166.5366667

Jeff Conrad

thanks jeff. it has been fixed. For Adak/Alaska we are now using the longitude -169.5 as the boundary.

Best

Marc

Marc,

The search queries now work fine, but queries using searchJSON still give the old values.

Unrelated, but for what it is worth: 49 CFR 71 is the official source for time zones in the United States, but I know of at least one instance where it is not followed. Fort Pierre, SD, is west of the Missouri River and technically in the Mountain time zone (UTC-7); however, the residents, including city and county offices, set their clocks to match the state capital Pierre, which is east of the Missouri River and in the Central time zone (UTC-6). This is how you currently have it, and for practical purposes, it's probably the correct value.

Jeff Conrad

Jeff

There are a couple of servers that need to be updated and it will take some days till it is available on all servers.

Do you happen to know the correct timezone for St. Lawrence Island in Alaska? My sources are not very clear about this. Is is the same as the western part of the Aleutian Islands?

Best

Marc

I have no particular knowledge of this; because it straddles the 169.5° W boundary given in 49 CFR 71, that document isn't dispositive. But given the island's remote location, having two different time zones would make little sense

Most sources that one finds in a Google search put it in Hawaii/Aleutian time zone (UTC-10); one of those sources is the State of Alaska ( http://www.commerce.state.ak.us/oed/student_info/learn/timezones.htm), so I'd assume that UTC-10 is the correct zone.

Jeff Conrad

Hi,

I think there´s an error with some spanish timezones.

A lot of cities from AL, BA, CA, CO, GR, H, J, MA, SE and MU provinces have the identifier "Africa/Ceuta"

Is it correct?

Not "Europe/Madrid"?

Thanks

Ups I see it´s ok on the web service.

Sorry then, maybe you'r still updating the database dump.

I will change it manually and wait for updates.

Regards
Xil

The dump has been updated.

Marc

Thanks Mark