GeoNames Forum

Has GeoNames considered adding in DST transition dates from zoneinfo? The iPhone app I'm developing needs to know whether a lat/lon is observing DST or not. I've googled for days trying to find a JSON feed with that data but found none. I think it would be a real coup if GN could add canonical DST data to it's services.

It'd help me out, too.

DZ

The timezone webservice returns some attributes that indicate whether there is DST right now or not. If the dstoffset equals the rawoffset (current) and is different from the gmtoffset then you know the location is currently using dst.

Best

Marc

hmmm... Let's try that.

Phoenix, AZ, has Mountain Standard time, no DST...ever. Their data is:

http://ws.geonames.org/timezone?lat=33.4483333&lng=-112.0733333

<countryCode>US</countryCode>
<countryName>United States</countryName>
<lat>33.4483333</lat>
<lng>-112.0733333</lng>
<timezoneId>America/Phoenix</timezoneId>
<dstOffset>-7.0</dstOffset>
<gmtOffset>-7.0</gmtOffset>
<rawOffset>-7.0</rawOffset>
<time>2010-03-21 07:15</time>

That checks out. Denver, CO, is also Mountain time, but observes DST:

http://ws.geonames.org/timezone?lat=39.7391667&lng=-104.9841667

<countryCode>US</countryCode>
<countryName>United States</countryName>
<lat>39.7391667</lat>
<lng>-104.9841667</lng>
<timezoneId>America/Denver</timezoneId>
<dstOffset>-6.0</dstOffset>
<gmtOffset>-7.0</gmtOffset>
<rawOffset>-7.0</rawOffset>
<time>2010-03-21 08:17</time>

Your logic states if dstOffset = rawOffset and rawOffset <> gmtOffset then DST else Standard Time:

(-6 == -7 && -7 != -7) yields FALSE, thus Standard Time

Doesn't work. US went to DST on 2010-03-14 (TimeZoneConverter.com, America/Denver)

One more for the northern hemesphere: New York, NY

http://ws.geonames.org/timezone?lat=40.6953437&lng=-80.3047846

<countryCode>US</countryCode>
<countryName>United States</countryName>
<lat>40.6953437</lat>
<lng>-80.3047846</lng>
<timezoneId>America/New_York</timezoneId>
<dstOffset>-4.0</dstOffset>
<gmtOffset>-5.0</gmtOffset>
<rawOffset>-5.0</rawOffset>
<time>2010-03-21 10:37</time>

(-4 == -5 && -5 != -5) yields FALSE, thus Standard Time

Nope: TimeZoneConverter.com, America/New_York

Auckland, New Zealand
http://ws.geonames.org/timezone?lat=-36.866667&lng=174.766667

<countryCode>NZ</countryCode>
<countryName>New Zealand</countryName>
<lat>-36.866667</lat>
<lng>174.766667</lng>
<timezoneId>Pacific/Auckland</timezoneId>
<dstOffset>12.0</dstOffset>
<gmtOffset>13.0</gmtOffset>
<rawOffset>12.0</rawOffset>
<time>2010-03-22 03:46</time>

(12 == 12 && 12 != -13) yeilds TRUE, thus DST

Head-desk time, TimeZoneConverter.com, Pacific/Auckland is in DST until 2010-04-04.

And besides, the timezone documentation says...

rawOffset: the amount of time in hours to add to UTC to get standard time in this time zone.
gmtOffset: offset to GMT at 1. January (deprecated)
dstOffset: offset to GMT at 1. July (deprecated)

Emphasis mine. So the rawOffset / gmtOffset / dstOffset comparison doesn't work and gmtOffset & dstOffset had enough problems that they were deprecated and could possibly go away.

P.S.: US is in DST from 2010-03-14 until 2010-11-07. Pacific/Auckland is in DST from 2009-09-27 to 2010-04-04.

you are right the raw offset is standard time. It would need a comparison between the time returned and the current utc time.

marc wrote:

you are right the raw offset is standard time. It would need a comparison between the time returned and the current utc time.

Unfortunately that won't work for Arizona, Saskatchewan or any region that doesn't observe DST. That's why I asked if the authoritative zoneinfo could be incorporated into your timezone service.

Hi,
enjoyed this forum but did not understand how it works for Sydney AU, April 5:
Lat -34, Long 151 gives DST 10, GMT 11, Raw 10 and the algorithm above DST= summertime while it should be wintertime from 1st Sunday in April.
How can DST be less than GMT?
Sincerely
Christer

Christer: the service does not distinguish between northern and southern hemisphere.

DataZombies: there are no plans to add anything more to the services regarding zoneinfo. This would be outside of the scope of this project.

Marc

Hi,
please can you explain me the difference between dstOffset, gmtOffset and rawOffset, thanks in advance for your reply

(sorry for the language I am a francophone)
Hi;
I have a website that displays the time of each users origin city, for displays a dynamic clock (with secondes) i needs to calculate the offset bitwin user time and gmt time for us it as a parameter to a javascript funtion. the problem is that i dont know is that should be used gmtoffset, or dstOffset rawOffset, especially since is that should be used rawOffset that gives the fixed timezone, dstOffset that gives the civil time offset from GMT on July 1st or gmtOffset that gives the civil time offset from GMT on January 1st

to give you an idea of my method here is the code:

function getTimeZone($lat, $lng)
{

// On définit un timeout si le service ne repond pas.
$context = stream_context_create(array('http' => array('timeout' => 3)));

$url = "http://ws.geonames.org/timezone?lat={$lat}&lng={$lng}";
$timedata = file_get_contents($url, 0, $context);

$sxml = simplexml_load_string($timedata);

return $sxml->timezone->dstOffset;

}

use the time from the webservice and get the gmt time from your local environment.
The other elements dstOffset, gmtOffset and rawOffset won't help you uch in this situation.

Best

Marc

thank you Mark, yes that's exactly what I did, I get the dstOffset with the getTimeZone method and after I use the local time with javascript to view a dynamic clock, but the problem is that I am not sure that Is what to get with the method getTimeZone (gmtOffset, dstOffset or rawOffset) for that return always the exact time whatever the month of the year

Is the dstOffset information from the webservice derived from the TZdata database in some manner ?
Because that one is considered to be THE standard and can provide detailed DST transition.

of course it is based on the olson dst rules. It is deprecated because it is easier to directly use the olson rules and it does not make sense for geonames to implement all dst methods as a webservice.

Marc

pfffff, in Morocco now it's GMT+1 but with geoname it's always GMT time, so..!!?

marc wrote:

of course it is based on the olson dst rules. It is deprecated because it is easier to directly use the olson rules and it does not make sense for geonames to implement all dst methods as a webservice.

Marc

Which means it really isn't.

is it your site have any limitation to get the timezone