Jump to content

TimeZones - a World Clock script filter [updated to v1.7]


Recommended Posts

Here's another little tool I've just whipped up:

 

screenshotnew.png

Get an instant list of the current time in various cities around the world. Which you can customize, of course.

 

  • Main keyword: tz (for TimeZones) - this just shows the World Clock list (seen above). (Select a city for a Large Type display.)
  • To remove a city from the list - option-select it.
  • To add a new city - timezone add Name of City
  • To update all cities' timezone offset information - timezone update
  • To look up the time in a place without storing it (custom loookup), just keep typing the place name after the initial tz (eg. tz timbuktu)
  • To move the location of your stored city list - timezone move

Download v1.7a

 

This workflow saves a list of your cities and their UTC offsets locally, so the basic world clock will display instantly. Adding new city information is done via an API call to Google Wolfram Alpha. The only downside to locally cached offsets is that there's no provision for automatically updating for Daylight Savings changes, but a manual timezone update will refresh all the cities with their current offset.

 

Enjoy. As usual, I welcome comments, bug reports, feature requests, etc. :)

 

----

 

28 March 2013 - UPDATE to v1.5

  • Major rewrite - now uses Google Maps APIs, which should be a lot more reliable and consistent.
  • Flag icons! Bit of eye candy, courtesy of http://www.free-country-flags.com (and managed to squeeze flags for every country in the world into just over 400k - thank you TinyPNG ;) )
  • More detail retrieved and displayed, including timezone name, country, etc.
  • When doing a full "update", a text file is saved to your Desktop summarising any changes found.
  • General enhancement and tweaks.

PLEASE NOTE: Because this version stores its data substantially different to previous versions, it will create a new timezones.txt file with default cities. However, it will attempt to save your old timezones.txt file to your Desktop, so you should be able to rebuild your previous list without too much hassle. B)

 

A quick note about the flags: The workflow simply compares the retrieved name of the country and does a simple name match against the workflow's local repository of flag icons. From my testing, it's working very well, but I'd appreciate it if you'd report back if you find any countries that don't properly match a flag icon. Cheers.

 

----

 

31 March 2013  - UPDATE to v1.6

  • New feature: Custom lookups. Just keep typing a new place name after the tz keyword to look up the time in a place without saving it to your saved list.
  • Added support for phyllisstein's Alleyoop auto-updater.
  • [EXPERIMENTAL] - support for autocomplete for adding place names (timezone add). You'll need to add a keyword yourself to the script filter if you want to try it out. The reason I haven't enabled it by default is that I've found it kind of slow and I'm not sure it's actually an improvement over the current method. Let me know what you think.
    screenshot20130331at945.png [Add a keyword to this script filter if you'd like to try it out]
  • Novelty: Added (unofficial) Antarctica flag to flag repository. (Try tz south pole. ;)  )

----

 

2 April 2013 — UPDATE to v1.61

  • Small fix for Dutch (Netherlands) flag matching.

 

----

 

22 March 2014 — UPDATE to v1.7

  • City List now always shows in the same order. (Achieved by removing “uid” parameter.)
  • Removed Alleyoop updater.

----


22 March 2014 — UPDATE to v1.7a

  •     New 256x256px icon
Edited by CarlosNZ
Link to comment

Thanks for the feedback guys.

 

I've updated it to 1.1 with the following changes:

  • Fixed the problem with cities with half-hour UTC offsets (eg. Adelaide—UTC+10.5, New Delhi—UTC+5.5
  • You can search the list of displayed cities (useful if you've got a lot) — just start typing after the "tz"
  • Hotkey to launch the list (set to Ctrl-Z by default)

B)

Link to comment

Nice workflow!  This will come in very handy at work.

 

One question, if you select one of the returned entries, Alfred learns that you "like" it more than other entries.

 

I'd prefer the order to remain static (time zone sorted, maybe?).  Is that possible by changing the output from the filter?  Do workflows have a way to tell Alfred to not learn the filter returns?

Link to comment
One question, if you select one of the returned entries, Alfred learns that you "like" it more than other entries.

 

I'd prefer the order to remain static (time zone sorted, maybe?).  Is that possible by changing the output from the filter?  Do workflows have a way to tell Alfred to not learn the filter returns?

We don't have a lot of control over the order that Alfred displays the results because, yes, he does "learn" your preferred choices and prioritise them. But personally, I thought it worked in this case having your "favourite" places near the top of the list.

 

However, if you'd rather the list remained "neutral", you could try the following, assuming you're comfortable with editing the script within the workflow:

 

Open up the script file "timezone_list.sh" from the workflow folder. Find this line:

 

echo '<item uid="'$city'" arg="'$city'|'$city_time'|'$city_date'" valid="yes">

and try changing it to this:

 

echo '<item uid="'$RANDOM'" arg="'$city'|'$city_time'|'$city_date'" valid="yes">

That'll just generate a random value for the uid, which Alfred uses to learn your preferences, so it'll be different every time and there'll be no "preference" to learn. Should work, haven't actually tried it myself.

 

Thanks for the the feedback. In a future version I might make this a user-selectable option (although it'll still be fairly "hidden" as I don't imagine too many people would want to change it.)

Link to comment

Interesting.  I'll take a look at the script.

 

I understand most folks not liking it, but I work in a global corporation, and have team members around the world.  I have used world clocks for the last 12+ years because of this, and my brain just looks for things in the order in which they "always" are.  Just in the first hour of using the script off and on my brain kinda broke in quickly finding the name in the list.

 

But that's me.  8)  Thanks for the code ideas.

Link to comment
Interesting.  I'll take a look at the script.

 

I understand most folks not liking it, but I work in a global corporation, and have team members around the world.  I have used world clocks for the last 12+ years because of this, and my brain just looks for things in the order in which they "always" are.  Just in the first hour of using the script off and on my brain kinda broke in quickly finding the name in the list.

 

But that's me.  8)  Thanks for the code ideas.

Let me know how it works out for you. And if you want complete control over the list order, you can probably manually edit the timezones.txt file. You'll find it at "~/Library/Application Support/Alfred 2/Workflow Data/carlosnz.timezones/timezones.txt". It should list them in that order initially, so combined with the $RANDOM uid, it'll probably keep them in your preferred order. Hopefully.

Link to comment

Okay updated version now available. (Updated initial post in this thread).

 

The version in the repo hasn't been updated yet, because it seems to be offline (is it like that for everyone?)

 

Let me know how it works for you. The data returned from Wolfram Alpha is now less consistent, and I've tried to account for every condition I've encountered, but it might have trouble with certain places, so let me know if you find any. For some reason, no Indian cities work anymore.

 

I'd like to find an alternative source for this info, so let me know if you've got any ideas. It needs to be flexible enough to interpret a city as input though.

 

Other improvements:

  • When doing a full "update", it won't fail the whole update if one city fails. A list of failed updates is saved to your Desktop.

 

Cheers,

 

C

Link to comment
  • 1 month later...

Great workflow Carl, I'm having trouble adding timezones though - I've tried a couple of different cities without any success. Have there been any further changes to Wolfram's API? Are there known issues or am I doing something wrong?

 

Thanks Jonathan. I think Wolfram might have been a bit flaky tonight. I just tried a few city additions, and the first few failed, but then it started working again. Have you tried again since posting? If it's still failing, what cities are you trying?

Link to comment

Hi Carlos, I'm still unable to add any time zones - just to test things out I've been trying "Istanbul", "Istanbul, Turkey", "Honolulu", "Cape Town". However, I just tried "timezone add Turkey" and the notification read that it was successful however it doesn't show up with the "tz" command. Additionally, when I try to update the timezones I get errors; the log is below:

 

 

The following cities had problems and were not updated:
Auckland
Sydney
New York
Los Angeles
London
Paris
Tokyo
Beijing
Capetown
Moscow
Dubai
 
I hope that helps.
Link to comment

Hi Jonathan,

 

that's odd, I just tried adding Istanbul and Honolulu and they worked fine. We should probably have a look at what the output you're getting from Wolfram is.

 

Are you comfortable editing the scripts within the workflow? (Sorry if this is condescending)

 

If so, open up the add_city.sh script and uncomment the following line:

 

#echo "$result" > ~/Desktop/result.xml 	#For debugging-uncomment to see full API result on Desktop

That is, remove the leading "#", so the line executes when run, and it will  now put an xml file on your Desktop when you try and update. If you wouldn't mind posting back with the contents of that file that'd be great.

 

Hope that makes sense. Let me know if you want further clarification.

Link to comment

Hi Carlos,

 

I'm fairly happy editing scripts - no worries there! So I uncommented the line in question and here's the dump from the XML file:

 

 

<?xml version='1.0' encoding='UTF-8'?>
<queryresult success='true'
    error='false'
    numpods='7'
    datatypes='City,TimeZone'
    timedout=''
    timedoutpods=''
    timing='6.881'
    parsetiming='0.119'
    parsetimedout='false'
    recalculate=''
    id='MSPa19821bea336fb6i8f6gb00004e7bhch571de1517'
    server='36'
    version='2.6'>
 <pod title='Input interpretation'
     scanner='Identity'
     id='Input'
     position='100'
     error='false'
     numsubpods='1'>
  <subpod title=''>
   <plaintext>Istanbul, Turkey | time zone</plaintext>
  </subpod>
 </pod>
 <pod title='Result'
     scanner='Identity'
     id='Result'
     position='200'
     error='false'
     numsubpods='1'
     primary='true'>
  <subpod title=''
      primary='true'>
   <plaintext>Eastern Europe Time</plaintext>
  </subpod>
 </pod>
 <pod title='Current time'
     scanner='Data'
     id='CurrentTimePod:TimeZoneData'
     position='300'
     error='false'
     numsubpods='1'>
  <subpod title=''>
   <plaintext>9:13:40 pm EET  |  Saturday, March 23, 2013</plaintext>
  </subpod>
 </pod>
 <pod title='Time zone map'
     scanner='Data'
     id='HomeCountryMap:TimeZoneData'
     position='500'
     error='false'
     numsubpods='1'>
  <subpod title=''>
   <plaintext></plaintext>
  </subpod>
 </pod>
 <pod title='Sample cities using EET'
     scanner='Data'
     id='IncludingCities:TimeZoneData'
     position='600'
     error='false'
     numsubpods='1'>
  <subpod title=''>
   <plaintext>Istanbul</plaintext>
  </subpod>
 </pod>
 <pod title='Changes in 2012 and 2013'
     scanner='Data'
     id='DSTChanges:TimeZoneData'
     position='700'
     error='false'
     numsubpods='1'>
  <subpod title=''>
   <plaintext>name | offset | beginning
EET | 0 hours  (clocks back 1 hour) | 1:00:00 am  |  Sunday, October 28, 2012
EEST | 1 hour  (clocks ahead 1 hour) | 1:00:00 am  |  Sunday, March 31, 2013
EET | 0 hours  (clocks back 1 hour) | 1:00:00 am  |  Sunday, October 27, 2013</plaintext>
  </subpod>
  <states count='1'>
   <state name='Longer period'
       input='DSTChanges:TimeZoneData__Longer period' />
  </states>
 </pod>
 <pod title='Currently at the same time as EET'
     scanner='Data'
     id='TimeZonesAtSameTime:TimeZoneData'
     position='800'
     error='false'
     numsubpods='1'>
  <subpod title=''>
   <plaintext>Central Africa Time (Botswana)  |  Central Africa Time (Burundi)  |  Central Africa Time (Democratic Republic of the Congo)  |  Central Africa Time (Malawi)  |  Central Africa Time (Mozambique)  |  Central Africa Time (Rwanda)  |  Central Africa Time (Zambia)  |  Central Africa Time (Zimbabwe)  |  Eastern European Time (Cyprus)  |  Eastern European Time (Jordan)  |  Eastern European Time (Lebanon)  |  Eastern European Time (Syria)  |  Eastern Europe Time (Bulgaria)  |  Eastern Europe Time (Estonia)  |  Eastern Europe Time (Finland)  |  Eastern Europe Time (Greece)  |  Eastern Europe Time (Latvia)  |  Eastern Europe Time (Lithuania)  |  Eastern Europe Time (Moldova)  |  Eastern Europe Time (Romania)  |  Eastern Europe Time (Ukraine)  |  Egypt East Time  |  Isreal Time (Israel)  |  South Africa Time (Lesotho)  |  South Africa Time (South Africa)  |  South Africa Time (Swaziland)</plaintext>
  </subpod>
  <states count='1'>
   <state name='Show map'
       input='TimeZonesAtSameTime:TimeZoneData__Show map' />
  </states>
 </pod>
 <sources count='2'>
      text='City data' />
      text='Time zone data' />
 </sources>
</queryresult>
Link to comment

That's weird, Jonathan, you're getting quite a different result from Wolfram than I am.

 

The relevant section in the returned data I get is this one:

<pod title='Current time differences'
     scanner='Data'
     id='CurrentTimeDifferences:TimeZoneData'
     position='400'
     error='false'
     numsubpods='1'>
  <subpod title=''>
   <plaintext>from NZDT | -11 hours (11 hours behind)
from UTC | +2 hours (2 hours ahead)</plaintext>
  </subpod>
 </pod>

In particular, the line giving the UTC difference, which is completely missing from your one. Very strange that you get a different result, although since my one shows the NZ time difference, it must be using your own location to customise what it returns. Where abouts in the world are you?

 

Has anyone else been getting errors? I'd be interested to know what kind of results people are getting from different locales.

 

I guess I'll have to look at getting a more robust method for always acquiring the correct data. If anyone can suggest how to be more precise with a Wolfram query, that'd be great (it seems its "fuzziness" feature is also a massive hassle when it comes to being specific and consistent.)

 

In the meantime (and I know this is a hassle), you can always go into in the timezones txt file and manually add an entry. It should be in "~/Library/Application Support/Alfred 2/Workflow Data/carlosnz.timezones" by default.

 

I keep looking into ways to get a more robust data return. Sorry.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...