Author |
Message |
26/01/2008 11:07:56
|
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
|
|
|
26/01/2008 13:05:24
|
marc
Joined: 08/12/2005 07:39:47
Messages: 4412
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
|
|
|
|
26/01/2008 13:15:56
|
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
|
|
|
26/01/2008 14:14:44
|
marc
Joined: 08/12/2005 07:39:47
Messages: 4412
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
|
|
|
|
26/01/2008 14:40:29
|
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
|
|
|
26/01/2008 14:52:53
|
marc
Joined: 08/12/2005 07:39:47
Messages: 4412
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
|
|
|
|
26/01/2008 14:57:40
|
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
|
|
|
12/05/2008 15:43:32
|
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)
|
|
|
12/05/2008 17:03:29
|
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
|
|
|
12/05/2008 17:34:15
|
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.
|
|
|
12/05/2008 22:01:28
|
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
|
|
|
13/05/2008 11:53:43
|
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!
|
|
|
18/05/2008 10:34:01
|
marc
Joined: 08/12/2005 07:39:47
Messages: 4412
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
|
|
|
|
30/07/2008 17:47:00
|
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.
|
|
|
02/08/2008 16:06:17
|
marc
Joined: 08/12/2005 07:39:47
Messages: 4412
Offline
|
Hi Gabriel
"rawOffset" and local current "time" are now also available in JSON.
Marc
|
|
|
|
03/08/2008 14:18:17
|
gabriel
Joined: 30/07/2008 17:44:57
Messages: 2
Offline
|
Two thumbs up, Marc!!
Thanks!
|
|
|
10/09/2008 12:07:33
|
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
|
|
|
|