DateTime API gets a ++
I don't know who he is, but DateTime is the only module mentioned in this thread on perlmonks with high praise: http://www.perlmonks.org/index.pl?node_id=339217 Though people might be interested: ... My favourite example of a module that gets this pretty-much right, IMO, is DateTime, which I can almost use in my sleep. ... Cheers! Rick Measham -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: Latitude/Longitude to Olson timezone name
On Fri, Mar 26, 2004 at 12:51:20AM -0600, Ed Perrone [EMAIL PROTECTED] wrote: I am working on an application where the user will input a date, time, and location, and I will need to convert that time into the equivalent GMT. This means I will need to locate the input data within one of the Olsen time zones in order to create and manipulate a Date::Time object. Unfortunately, city/province/nation or latitude/longitude don't seem to convert easily into the time zone names used in Date::Time. Example: User inputs May 15, 1973, Austin, TX, USA. I need to figure out which of the Olsen zones Austin TX is located in. I will have available the city/state-province/nation name, as well as ISO-3166-2 codes for US/Canada states/provinces, FIPS 10-4 codes for other nations/regions, and longitude/latitude of the specific place in question. What I need to find from this is the proper time zone to use for that date/location. Does anyone know of any tool or routine that might be able to do this type of conversion? Many thanks! You could go through the comments in the Olson files; they will say where the timezones apply, and you should be able to come up with a pretty good state/nation-timezone table. (If you do this, please post it here.) For some of the U.S. states, it is helpful to know the county. There's also a zone.tab file that gives latitude/longitude for the cities the timezones are named after. As a last ditch guess, you could pick the one that's closest. The original files can be found at: ftp://elsie.nci.nih.gov/pub/tzdata2003e.tar.gz
Re: Latitude/Longitude to Olsen timezone name
I am working on an application where the user will input a date, time, and location, and I will need to convert that time into the equivalent GMT. This means I will need to locate the input data within one of the Olsen time zones in order to create and manipulate a Date::Time object. Unfortunately, city/province/nation or latitude/longitude don't seem to convert easily into the time zone names used in Date::Time. Example: User inputs May 15, 1973, Austin, TX, USA. I need to figure out which of the Olsen zones Austin TX is located in. I will have available the city/state-province/nation name, as well as ISO-3166-2 codes for US/Canada states/provinces, FIPS 10-4 codes for other nations/regions, and longitude/latitude of the specific place in question. What I need to find from this is the proper time zone to use for that date/location. Does anyone know of any tool or routine that might be able to do this type of conversion? G'day Ed, Unfortunately there is no (easy) way to do this. We've looked at it before, but it just isn't possible. Using a vector-map of the world, it is possible to calculate a person's country based upon their long/lat, but that will only be correct until the political boundaries change. Also, such a map, zipped, is about 16MB. Next, countries are of little use for the above reason: they're political boundaries and are prone to change. Because of this, the Olsen database uses geographic areas (continents) and city names -- which are far less likely to change. Same for states. Now the Olsen database gets even more confusing, but more reasonable in that it doesn't even use the local capital city. It uses the largest city in the time zone, thus we have America/Los Angeles rather than America/Sacramento, and Australia/Sydney rather than Australia/Canberra (Sydney is a capital, but it's just a state capital whereas Canberra is the federal capital). Once again this is because politics change. Now, as for I need to figure out which of the Olsen zones Austin TX is located in., I can offer a solution: Ask the user. We can do a few neat tricks with online resources here (and maybe we should look at including the first part with DateTime). 1. Determine and catalog a list of long/lat coords for every time zone's major city. (already done in the Olsen database, just needs perlifying. 2. Determine (by some means) the user's long/lat coords. 3. Use Math::Trig to determine the great-circle-distance to each zone's coords We can then present the user with the closest 3, 4, 5, ... (you pick) zones and ask which they're in. Hope this helps at least in some small way. Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
ANNOUNCE: DateTime 0.21
0.21 2004-03-28 (The Another YAPC::Taipei release party release release) [ *** BACKWARDS INCOMPATIBILITIES *** ] - When given mixed positive negative arguments, DateTime::Duration no longer forces all arguments to be negative. - For mixed durations, the is_positive, is_zero, and is_negative methods all return false. - Brought back stringification overloading. As of version 1.06, Devel::StackTrace will ignore this overloading when displaying a trace. [ ENHANCEMENTS ] - Add a new in_units() method to DateTime::Duration. Patch by Andrew Pimlott. - Rely on DateTime::TimeZone and DateTime::Locale having their own Storable hooks, as opposed to handling them in DateTime.pm's own Storable hooks. This should fix RT ticket #5542, reported by Dan Rowles (I hope). - More docs on how date math is done. See the new section The Results of Date Math. [ BUG FIXES ] - DateTime::Duration's is_positive, is_zero, and is_negative methods could incorrectly return true if a duration contained mixed positive and negative units. - Better normalization of nanoseconds in DateTime::Duration. Patch by Andrew Pimlott. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Latitude/Longitude to Olson timezone name
Yitzchak Scott-Thoennes wrote: You could go through the comments in the Olson files; they will say where the timezones apply, and you should be able to come up with a pretty good state/nation-timezone table. (If you do this, please post it here.) For some of the U.S. states, it is helpful to know the county. There's also a zone.tab file that gives latitude/longitude for the cities the timezones are named after. As a last ditch guess, you could pick the one that's closest. There is also another .tab file (I've forgotten its name) in the Olson distribution that contains a list of countries (ISO 2-letter codes) and corresponding timezones. This could perhaps be converted automatically to timezone aliases. Eugene -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
Re: ANNOUNCE: DateTime 0.21
Dave Rolsky wrote: - When given mixed positive negative arguments, DateTime::Duration no longer forces all arguments to be negative. - For mixed durations, the is_positive, is_zero, and is_negative methods all return false. Is it possible to detect mixed durations other than checking all of is_positive, is_zero and is_negative? For example by adding an is_mixed method? You could also change the behaviour of is_positive etc., returning 0 for negative or zero, and undef for 'unknown' (mixed durations). Eugene -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
Re: Latitude/Longitude to Olson timezone name
On Sun, Mar 28, 2004 at 04:32:43PM +0200, Eugene van der Pijll [EMAIL PROTECTED] wrote: Yitzchak Scott-Thoennes wrote: You could go through the comments in the Olson files; they will say where the timezones apply, and you should be able to come up with a pretty good state/nation-timezone table. (If you do this, please post it here.) For some of the U.S. states, it is helpful to know the county. There's also a zone.tab file that gives latitude/longitude for the cities the timezones are named after. As a last ditch guess, you could pick the one that's closest. There is also another .tab file (I've forgotten its name) in the Olson distribution that contains a list of countries (ISO 2-letter codes) and corresponding timezones. This could perhaps be converted automatically to timezone aliases. Those are in zone.tab also.
ANNOUNCE: DateTime::Set 0.15
DateTime::Set 0.15 2004-03-28 [ ENHANCEMENTS from version 0.14 ] - Both Makefile.PL and Build.PL are provided. - New methods: DateTime::SpanSet::current DateTime::Spanset::closest DateTime::Set::map / grep DateTime::SpanSet::map / grep DateTime::SpanSet::intersected_spans DateTime::SpanSet::start_set / end_set - Recurrences can be bounded sets. - Recurrences can be as small as 1 nanosecond. - DateTime::SpanSet::duration may return an 'infinite' DateTime::Duration (instead of scalar infinity). [ *** BACKWARDS INCOMPATIBILITIES from version 0.14 *** ] - The next/previous functions used in DT::Set-from_recurrence() MUST work with DateTime::Infinite::Future and DateTime::Infinite::Past parameters. Failing to test for infinity values is known to cause an INFINITE LOOP in some modules. - DateTime::Set and DateTime::SpanSet methods do not mutate the set. This was the behaviour in version 0.13 - Flavio S. Glock
Re: Latitude/Longitude to Olson timezone name
Thanks for all the suggestions. I have been looking through the Olsen distribution files (zone.tab, etc.), and was considering making up a conversion table. I just didn't want to re-invent the wheel if it had already been done. Now, as for I need to figure out which of the Olsen zones Austin TX is located in., I can offer a solution: Ask the user. Wel.. mebbe. But you have to assume the user is dumb and doesn't know. :-) There is commercial software that does all this. It is the International Atlas, based on the Shanks time-changes books and published by the same people. I don't know what system they use for their lookups -- probably some sort of internal conversion table of the same type we're discussing here. They charge mucho bucks for their software, especially for use in a Web environment. Since no one has actually done it yet, I will go ahead and see if I can make up some kind of a lookup/conversion table. (I'm apparently going to have to do this anyway for my client's project.) I will make the results available here, and if there's some way they can be integrated into DateTime, I think it might make a lot of people happy. (Of course, that means such a table would have to be updated periodically, to take into account political changes, etc.) Anyways, I will see what I can come up with and let y'all know. --- Ed Ed Perrone Interactive Web Development [EMAIL PROTECTED] http://www.edperrone.com
Re: Latitude/Longitude to Olson timezone name
And to ask a nasty question... will it support localization? Or I suppose if your mapping is from lat/long to TZ then the localization problem will be in the code for taking a location name and producing the lat/long. Which makes this more tractable. -ben On Sun, Mar 28, 2004 at 05:52:41PM -0600, Ed Perrone wrote: Thanks for all the suggestions. I have been looking through the Olsen distribution files (zone.tab, etc.), and was considering making up a conversion table. I just didn't want to re-invent the wheel if it had already been done. Now, as for I need to figure out which of the Olsen zones Austin TX is located in., I can offer a solution: Ask the user. Wel.. mebbe. But you have to assume the user is dumb and doesn't know. :-) There is commercial software that does all this. It is the International Atlas, based on the Shanks time-changes books and published by the same people. I don't know what system they use for their lookups -- probably some sort of internal conversion table of the same type we're discussing here. They charge mucho bucks for their software, especially for use in a Web environment. Since no one has actually done it yet, I will go ahead and see if I can make up some kind of a lookup/conversion table. (I'm apparently going to have to do this anyway for my client's project.) I will make the results available here, and if there's some way they can be integrated into DateTime, I think it might make a lot of people happy. (Of course, that means such a table would have to be updated periodically, to take into account political changes, etc.) Anyways, I will see what I can come up with and let y'all know. --- Ed Ed Perrone Interactive Web Development [EMAIL PROTECTED] http://www.edperrone.com
