GeoNames Home | Postal Codes | Download / Webservice | About 

GeoNames Forum
  [Search] Search   [Recent Topics] Recent Topics   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Time Zone DST and GMT  XML
Forum Index -> General
Author Message
schmidtze



Joined: 26/01/2008 10:53:06
Messages: 4
Offline

Hi,

to get the time zone fory Sydney (Australia), I'm using the request http://ws.geonames.org/timezone?lat=-33.867139&lng=151.207114 which returns 11.0 for GMT and 10.0 for DST. Because the time zone of Sydney without considering Daylight Saving Time is +10, I'm asking if it is perhaps possible that the service mixes up the 2 values because of a bug? As far as I know there's Daylight Saving Time in Sydney at the moment. To get the time zone, I'm always using the value "gmtOffset" which is correct for Germany for example.

Perhaps I didn't understand the description of the service, because it says

Result : the timezone at the lat/lng with gmt offset (1. January)
and dst offset (1. July)

What does the additional information about "1. January" and "1. July" mean?

Best regards
Friedemann
marc



Joined: 08/12/2005 07:39:47
Messages: 3745
Offline

Hi Friedemann

The service basically returns the timezone name and it gives the gmt offset at the first of January of this year and the first of July of this year.
It does not give the gmt offset of today. We could add another element with the current time and/or current gmt offset, if there is interest in this information. Would it be of any value to you or just redundant noise?

You are right for the southern hemisphere the name 'dst-offset' does not make sense and is misleading.

Cheers

Marc

[WWW]
schmidtze



Joined: 26/01/2008 10:53:06
Messages: 4
Offline

Hi Marc,

many thanks for your quick reply! What I need is the time zone regardless of Daylight Summer Time and regardless the date because I think the time zone doesn't change over the year. Is this already possible right now? Do I perhaps have to take "dst-offset" for southern hemnisphere and "gmt-offset" for northern hemnisphere? In my eyes it wouldn't make sense because of the naming, but if it would work in general, it would be ok

By the way: I want to thank you for your service and all your work you spend on it!!! I'm using it in my freeware application GeoSetter. I hope this is ok.

Best regards
Friedemann

marc



Joined: 08/12/2005 07:39:47
Messages: 3745
Offline

Hi Friedemann

I think the timezoneId should be sufficient for your needs. The actual offset depends on year and data and the timezone rules.
The timezoneId referse to the Olson Timezones :
http://www.twinsun.com/tz/tz-link.htm

Cheers

Marc

[WWW]
schmidtze



Joined: 26/01/2008 10:53:06
Messages: 4
Offline

Hi Marc,

ok, thank you. As far as I see by now, I can use the files in tzdata2007k.tar.gz. But then I don't understand your time zone service, because I expected to get the time zone from it. I only was confused because it returns the correct value for Germany, but not for Australia. But because this subject is new for me, I perhaps have som difficulties to understand it and mixing up the terminology. I thought that "time zone" doesn't include any values regarding Daylight Saving Time.

Best regards
Friedemann
marc



Joined: 08/12/2005 07:39:47
Messages: 3745
Offline

Hi Friedman

The important part of the service is the element 'timezoneId'. The offset is redundant and only included because users have been asking for it.

The tddata file will help you figure out the gmt offset for the timezoneId, but it wan't help you find the timezoneId for a lat/lng.

Cheers

Marc

[WWW]
schmidtze



Joined: 26/01/2008 10:53:06
Messages: 4
Offline

Hi Marc,

yes, I understand. I'll get the TimeZoneID by using your service and then get the time zone from tzdata. Unfortunately I didn't find a ready to use solution for Borland Delphi, so I have to code it for myself.

Thanks again + best regards
Friedemann
nev



Joined: 12/05/2008 13:59:33
Messages: 3
Offline

Hello everybody!

I'm confused!

The poster seemed to want to get time zone information for a given lat/long co-ordinate.

As I understand it, a query to geonames like this:

http://ws.geonames.org/timezone?lat=-33.867139&lng=151.207114

...will return an XML file with, among other things, these data:

1. A "timezoneId" value, which identifies the location in the Olson tz database;
2. A "gmtOffset" value, which shows the location's timezone (offset from GMT).

I hope I have that right. (I know the query returns other data as well.)

The poster appeared to think he couldn't get time zone data from the query, and Marc seemed to reinforce this when he said "The actual offset depends on year and data and the timezone rules" (meaning I guess the Olson tz data).

But I don't understand: doesn't the query return the location's time zone (offset from GMT) in the "gmtOffset" value? If not, what does that value represent?

Also, why is the value for "1st January of the current year"? Considering the existence of the other "dstOffset" value, it sounds like there's some attempt to take Daylight Savings into account.. But a place's time zone (offset from GMT) is fixed all year round, not changing (unless there's new legislation)

Steven



Joined: 31/12/2006 16:08:18
Messages: 8
Offline

As far as I understand, gmtOffset gives the offset from GMT on January 1 and dstOffset the offset from GMT on July 1. This means that for places on the southern hemisphere where daylight saving time is used, the standard timezone offset is returned by dstOffset, while the timezone offset during daylight saving time is returned by gmtOffset. On the northern hemisphere, it's the other way around. If no daylight saving time is used, gmtOffset and dstOffset return the same value.

Hope this helps,

Steven
nev



Joined: 12/05/2008 13:59:33
Messages: 3
Offline

Steven wrote:
As far as I understand, gmtOffset gives the offset from GMT on January 1 and dstOffset the offset from GMT on July 1. 


So these values are not the same as the place's Time Zone, since a place's Time Zone does not vary. (Sure, a place can be observing Daylight Savings or not at any given time, but that's separate from its Time Zone, which is a fixed number of hours by which it deviates from GMT.)

Steven wrote:
This means that for places on the southern hemisphere where daylight saving time is used, the standard timezone offset is returned by dstOffset, while the timezone offset during daylight saving time is returned by gmtOffset. On the northern hemisphere, it's the other way around. If no daylight saving time is used, gmtOffset and dstOffset return the same value. 


Er.. ?

I'm just trying to get a place's time difference from GMT. I was looking at Daylight Savings as a different issue, which would have been the next thing to account for.

Basically my goal is this: I have a number of times and associated locations, and I need to find the GMT for each time and location, worldwide. I thought, first, adjust for the place's difference to/from GMT (its time zone), and secondly, add another hour if the place was observing Daylight Savings Time.


Steven



Joined: 31/12/2006 16:08:18
Messages: 8
Offline

Ok, I looked at it a little closer.

rawOffset gives the fixed timezone.
dstOffset gives the civil time offset from GMT on July 1st
gmtOffset gives the civil time offset from GMT on January 1st

On the southern hemisphere, for example for Chile (http://ws.geonames.org/timezone?lat=-33.46912&lng=-70.641997) we have the following values:
rawOffset = -4 indicating the timezone
dstOffset = -4
gmtOffset = -3, which means that daylight saving time is in use in January.

On the northern hemisphere, for the Netherlands for example (http://ws.geonames.org/timezone?lat=51.589322&lng=4.774491):
rawOffset = 1
dstOffset = 2
gmtOffset = 1, indacting that daylight saving time is in use in July.

Steven
nev



Joined: 12/05/2008 13:59:33
Messages: 3
Offline

I see. So rawOffset is effectively the time zone.

And dstOffset is like the "JulyOffset", while gmtOffset is like the "JanuaryOffset".

So, you get fixed timezone info, and also a general indication, at least, that DST is in effect in the middle of the period that's relevant to the location's hemisphere.

That leaves DST rules wide open of course, but it's a neat use of the data.

Thanks Steven for clarifying that for me!

I think the addition of another element with the current time and current raw, gmt and dstoffset, as marc suggested above, would be worth it!

marc



Joined: 08/12/2005 07:39:47
Messages: 3745
Offline

Nev

The "timezoneId" is sufficient if you use a programming environment such as java that includes the Olson timezone rules. Everything else is redundant information.
The "rawOffset" gives the offset from GMT and the "time" gives the current time. I am not happy with the fields "gmtOffset" and "dstOffset" they are quite misleading, but do basically what Steven has said.

Marc

[WWW]
gabriel



Joined: 30/07/2008 17:44:57
Messages: 2
Offline

Hello,

Thank you so much for these wonderful services.

I would find it very helpful if the rawOffset attribute was published in the JSON version of the Timezone service...

Thanks!
Gabriel.
marc



Joined: 08/12/2005 07:39:47
Messages: 3745
Offline

Hi Gabriel

"rawOffset" and local current "time" are now also available in JSON.

Marc

[WWW]
gabriel



Joined: 30/07/2008 17:44:57
Messages: 2
Offline

Two thumbs up, Marc!!
Thanks!
omega



Joined: 10/09/2008 12:00:18
Messages: 1
Offline

marc wrote:
Hi Friedemann

The service basically returns the timezone name and it gives the gmt offset at the first of January of this year and the first of July of this year.
It does not give the gmt offset of today. We could add another element with the current time and/or current gmt offset, if there is interest in this information. Would it be of any value to you or just redundant noise?

You are right for the southern hemisphere the name 'dst-offset' does not make sense and is misleading.

Cheers

Marc 


Hi Marc,

something that would be great is having the possibility to specify a UTC time together with lat/lon and then to get back the corresponding local time (calculated with the Olson database). Having this I wouldn't need to add all the Olson stuff (including handling database updates) to my program.

Any chance that this will be implemented sometimes?

Andreas
 
Forum Index -> General
Go to:   
Powered by JForum 2.1.5 © JForum Team