I've been creating kml files for a while now, using TimeStamps so that I can use the time scaling control. It used to be that times specified as UTC (with a 'Z' character at the end) would not be changed by Google Earth. They've apparently changed their approach and now adjust the UTC time to the local time of wherever a Placemark is located. For example:
<Placemark>
<name>1324</name>
<description>Local time: 13:50:12</description>
<Point>
<altitudeMode>relativeToGround</altitudeMode>
<coordinates>-79.344437,43.679943,0</coordinates>
</Point>
<TimeStamp><when>2012-09-26T13:50:12Z</when></TimeStamp>
</Placemark>
This location is set to 13:50:12 (1:50:12 PM), but will appear in the time slider control as 08:50:12, the "adjusted" local time for Toronto (North American Eastern Time Zone). I tried different formats for the timestamp:
<TimeStamp><when>2012-09-26T13:50:12Z</when></TimeStamp>
<TimeStamp><when>2012-09-26T13:50:12</when></TimeStamp>
<TimeStamp><when>2012-09-26T13:50:12+00:00</when></TimeStamp>
<TimeStamp><when>2012-09-26T13:50:12-00:00</when></TimeStamp>
And only specifying the offset (which I want to avoid) makes Google Earth give out the correct time:
<TimeStamp><when>2012-09-26T13:50:12-05:00</when></TimeStamp>
What is the format (if any) to tell Google Earth to ignore the timezone, to basically not adjust times?
Add-on: Working example at http://pastebin.com/DahChjsT, save as .kml and open.
Using latest version of free Google Earth, 7.0.1.8244 (beta)
I assume you are talking about the desktop version of Google Earth and not the web based API. That being said, if you make the time stamps with the normal Z notation, the time slider bar will appear and if you click the wrench on the slider it brings up the time options and you can select UTC as the time you want to use. This seems to stick when closing and re-opening the program. Hope that helps.
Related
We're currently storing local datetime of Pacific/Hawaii in the database. Assuming that I cannot change these dates to UTC, what information do I need to add to support timezone?
My thoughts are:
First, add a timezone field to indicate which timezone the user is viewing from. (The user will select this from a dropdown)
Second, add timezone field to indicate the timezone (Pacific/Hawaii) of the current datetimes values in the database.
Third, add offset to cover DST hours
So say a user from America/Los_Angeles views the site, it would pull the datetime from the database, append the offset and apply the timezone of Hawaii before converting it to Los Angeles time. For any calculation or comparison I would convert the Hawaii time to UTC first, then convert the UTC result to Los Angeles. Am I missing anything?
Your question is very broad, and without knowing more about your application, the platform, how you use collect dates and times, what they represent, etc., I can only speak in generalities.
Storing in UTC is recommended, but that is just by convention. The main necessities are that the time zone you are storing data in does not have DST (which Hawaii hasn't since 1947), and that you do not rely on your computer's operating system or environment settings to determine what time zone to use. You can use the Hawaiian time zone if you must. Be sure you document it somewhere though! It will surely be a surprise to anyone else that comes along in the lifecycle of the application.
While it would wolk, there is absolutely no advantage to doing this. You could just as easily convert your data to UTC when you roll out these changes and use UTC going forward. (That would be the preferred approach.)
The IANA time zone ID for Hawaii is "Pacific/Honolulu". If you're on Windows/.Net, the TimeZoneInfo ID is "Hawaiian Standard Time". Either way, they must be spelled, cased, and punctuated in exactly that manner.
Make sure you understand that a Time Zone Offset and a Time Zone are two different concepts. While Hawaii may use a fixed offset of -10:00, that's not guaranteed for most time zones. Please read the timezone tag wiki for further details.
You should probably not attempt to implement your own time zone logic. There are libraries for this in almost every language. Look to see what is appropriate for your platform. (If you provide details, I can offer suggestions.)
It would be a more robust solution to store the times as UTC time as time zone is local to the specific PC that is displaying the data. In your case if you store time plus offset how can you decide which offset to store? Not a workable solution if multiple time zones are involved.
I live in a country where they change the time twice a year. That is: there is a period in the year when the offset from UTC is -3 hours (-180 mins) and other period where the offset is -4 hours (-240 mins)
Grafically:
|------- (offset = -3) -------|------- (offset is -4) -------|
start of year mid end of year
My question is:
the "timezone" is just the number representing the offset? that is: my country has two timezones? or the timezone includes this information?
This is important because I save every date in UTC timezone (offset = 0) in my database.
Should I, instead, be saving the dates with local timezone and saving their offset (at the moment of saving) too?
Here is an example of a problem I see by saving the dates with timezone UTC:
Lets say I have a system where people send messages.
I want to have a statistics section where I plot "messages sent v/s hour" (ie: "Messages sent by hour in a regular day")
Lets say there are just two messages in the whole database:
Message 1, sent in march 1, at UTC time 5 pm (local time 2 pm)
Message 2, sent in august 1, at UTC time 5 pm (local time 1 pm)
Then, if I create the plot on august 2, converting those UTC dates to local would give me: "2 messages where sent at 1 pm", which is erratic information!
From the timezone tag wiki here on StackOverflow:
TimeZone != Offset
A time zone can not be represented solely by an offset from UTC. Many
time zones have more than one offset due to "daylight savings time" or
"summer time" rules. The dates that offsets change are also part of
the rules for the time zone, as are any historical offset changes.
Many software programs, libraries, and web services disregard this
important detail, and erroneously call the standard or current offset
the "zone". This can lead to confusion, and misuse of the data. Please
use the correct terminology whenever possible.
There are two commonly used database, the Microsoft Windows time zone db, and the IANA/Olson time zone db. See the wiki for more detail.
Your specific questions:
the "timezone" is just the number representing the offset? that is: my country has two timezones? or the timezone includes this information?
You have one "time zone". It includes two "offsets".
Should I, instead, be saving the dates with local timezone and saving their offset (at the moment of saving) too?
If you are recording the precise moment an event occurred or will occur, then you should store the offset of that particular time with it. In .Net and SQL Server, this is represented using a DateTimeOffset. There are similar datatypes in other platforms. It only contains the offset information - not the time zone that the offset originated from. Commonly, it is serialized in ISO8601 format, such as:
2013-05-09T13:29:00-04:00
If you might need to edit that time, then you cannot just store the offset. Somewhere in your system, you also need to have the time zone identifier. Otherwise, you have no way to determine what the new offset should be after the edit is made. If you desire, you can store this with the value itself. Some platforms have objects for exactly this purpose - such as ZonedDateTime in NodaTime. Example:
2013-05-09T13:29:00-04:00 America/New_York
Even when storing the zone id, you still need to record the offset. This is to resolve ambiguity during a "fall-back" transition from a daylight offset to a standard offset.
Alternatively, you could store the time at UTC with the time zone name:
2013-05-09T17:29:00Z America/New_York
This would work just as well, but you'd have to apply the time zone before displaying the value to anyone. TIMESTAMP WITH TIME ZONE in Oracle and PostgreSQL work this way.
You can read more about this in this post, while .Net focused - the idea is applicable to other platforms as well. The example problem you gave is what I call "maintaining the perspective of the observer" - which is discussed in the same article.
that is: my country has two timezones? or the timezone includes this information?
The term "timezone" usually includes that information. For example, in Java, "TimeZone represents a time zone offset, and also figures out daylight savings" (link), and on Unix-like systems, the tz database contains DST information.
However, for a single timestamp, I think it's more common to give just a UTC offset than a complete time-zone identifier.
[…] in my database.
Naturally, you should consult your database's documentation, or at least indicate what database you're using, and what tools (e.g., what drivers, what languages) you're using to access it.
Here's an example of a very popular format for describing timezones (though not what Windows uses).
You can see that it's more than a simple offset. More along the lines of offsets and the set of rules (changing over time) for when to use which offset.
Task: Given every zipcode of locations in US, I need to get the exact utf_timeoffset and exact dst(daytime savings offset), but I can ignore zip_code belonging to AP/FPO/DPO.
I need take into account of the timezone differences inside each state, and also need care about the exception of Hawaii, Arizona and several zipcode in PR, VI when it comes to daylight savings between Mar 11 2013, 2:00 and Nov 3 2013, 2:00.
I wonder if there is a standard module existing in Pytz(the famous timezone s/w package), because I can't located any proper function with zip_code parameter. Besides, I am perfectly fine with other package than pytz, and also any other programming languages other than Python.
At the same time, with some handmade code, I have managed to get "time_zone name" and "utf_time offset" for each zip_code. Based on provision of some websites, I also managed to get a copy of dataset containing zip_code and their daylight savings flag. A.K.A the current dst policy for each zip_code in US)
So far It works fine, but I dont really trust my own code, didn't get a way to validate its correctness.
No, pytz do not have such a functionality. See also: Mapping US zip code to time zone
Do you have the option to use the raw ZIP code data? Because if you do, it might be very helpful to use a zip code database such as the kind you would find here. They have the ZIP code associated with specific time zones as well as daylight savings info for each one. Looks like the annual price is currently $139 for 12 monthly updates.
I don't work there but I know a lot about ZIP codes and addresses since I work at SmartyStreets.
I need to display today's sunrise and sunset at Easter Island in local Easter Island time. I'm implementing it to the sidebar at http://www.easterislandtraveling.com/easter-island/
I noticed the EarthTools (http://www.earthtools.org/webservices.htm#sun) only covers Europe and USA. Is there any other way?
Over at http://www.timeanddate.com/worldclock/astronomy.html?n=914 they have all the necessary data.
I was playing around some with the standard PHP functions date_sun_info(), date_sunrise() and date_sunset() but I couldn't get them to work well with the local timezone.
I found a website that offers the service I'm looking for:
http://www.happyzebra.com/widgets/sunrisesunset.php?city=Easter%20Island
Works great! Only differed 2 minutes on the sunrise compared to http://www.timeanddate.com/worldclock/city.html?n=914
I am basically trying to read a .vcs file in Android. It has timezone value in the below format:
TZ:+05:30
Now I want to get the timezone name corresponding to this value. Means in this case it would be Kolkata(India).
Is there any code to achieve this in android?
TimeZone tz = TimeZone.getTimeZone("GMT-06:00");
String tzarr[] = TimeZone.getAvailableIDs(tz.getRawOffset());
for(int i=0;i<tzarr.length;i++)
(I'm assuming you can parse the text into an offset easily enough.)
In general, you can't. Something like "+05:30" just represents an offset from UTC at one particular time. It doesn't express how the offset changes within the time zone across the year (or across history). For example, for some of the time the Europe/London time zone has the same offset as Africa/Casablanca - but not always.
Assuming this is associated with a specific date/time, you could use TimeZone.getAvailableIDs, iterate over all the time zones, check what the offset from UTC is at that particular instant (using TimeZone.getOffset(long)) and see which time zones have the right offset at the right time. There could be many such zones though.
If you don't have a specific date/time, it's even more ambiguous. You can use getRawOffset and getDSTSavings to see whether the target offset is either the standard or DST offset for any particular zone - although note that these calls assume that for a particular time zone, the DST offset and standard offset remain the same across history (which isn't always true).