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

[parekh]

You only have to do it every six months, and most of the world changes to DST within a couple of weeks of each other. In fact, for live results like the one in your example, you would only need to update when YOUR location changes to or from DST.

 

Yes, it's a little cumbersome, but that's what allows the main workflow list of cities to be so fast — the timezone offsets are stored locally. If it had to check the current offset for every saved city every time, the list would be a LOT slower.

 

Thank you for your message, but I'm having some difficulty understanding what you're saying. How does it depend on my city or my location? Doesn't it depend on the target city? I actually came here because I've run into the same problem again. Here's a timeline of my problem:

• March 5: I want to know the time in Los Angeles. The information displayed is incorrect. I have to run the timezone update to fix the problem.
• March 10: Once again, I want to know the time in Los Angeles. The information displayed is incorrect. I have to run the timezone update to fix the problem.

Between March 5 and March 10, there was no change in my time zone. I have been on Central European Time for this entire duration. The only thing that changed was the time zones in the United States. So I'm not sure how any of this depends on my city or my location. 

[CarlosNZ]

Thank you for your message, but I'm having some difficulty understanding what you're saying. How does it depend on my city or my location? Doesn't it depend on the target city?

The workflow calculates the difference between the requested city and your local time (as per your computer's clock) and stores it as an offset from your computer time.

 

I actually came here because I've run into the same problem again. Here's a timeline of my problem:

• March 5: I want to know the time in Los Angeles. The information displayed is incorrect. I have to run the timezone update to fix the problem.
• March 10: Once again, I want to know the time in Los Angeles. The information displayed is incorrect. I have to run the timezone update to fix the problem.

Between March 5 and March 10, there was no change in my time zone. I have been on Central European Time for this entire duration. The only thing that changed was the time zones in the United States. So I'm not sure how any of this depends on my city or my location.

Are you doing a "live" lookup (ie. "tz place-not-saved"), or do you have Los Angeles stored in your quick list (ie. keyword "tz")? If the latter, then yes, the US has recently changed to DST so a refresh of saved offsets will have been required. If the former, then that result should be correct regardless.

 

I'm not sure why you had to update last week and again today. The only thing I can think of is that it might have been a long time (ie nearly 6 months) since you last used the workflow so DST had expired, and then it was re-implemented just this last weekend.

 

Perhaps in a future update, I'll be able to store the DST change dates with the saved cities and automatically account for it or, at the very least, remind the user to manually update. I'll see if I can find some time to have a look at that in the near future. Thanks for your input.

[parekh]

The workflow calculates the difference between the requested city and your local time (as per your computer's clock) and stores it as an offset from your computer time.

 

Are you doing a "live" lookup (ie. "tz place-not-saved"), or do you have Los Angeles stored in your quick list (ie. keyword "tz")? If the latter, then yes, the US has recently changed to DST so a refresh of saved offsets will have been required. If the former, then that result should be correct regardless.

 

I'm not sure why you had to update last week and again today. The only thing I can think of is that it might have been a long time (ie nearly 6 months) since you last used the workflow so DST had expired, and then it was re-implemented just this last weekend.

 

Perhaps in a future update, I'll be able to store the DST change dates with the saved cities and automatically account for it or, at the very least, remind the user to manually update. I'll see if I can find some time to have a look at that in the near future. Thanks for your input.

 

Thank you very much for following through on this issue with me; I really appreciate it. Just one final question: you mentioned something about a quick list. Could you please let me know how to check which cities are currently stored in my quick list and how to add more cities to this quick list? 

 

If I understand you correctly you're saying that the time for quick list cities will ALWAYS be accurate regardless of whether or not I have recently run a timezone update. Is this correct? Thanks.

Edited March 14, 2014 by parekh

[CarlosNZ]

Thank you very much for following through on this issue with me; I really appreciate it. Just one final question: you mentioned something about a quick list. Could you please let me know how to check which cities are currently stored in my quick list and how to add more cities to this quick list? 

These instructions are all in the first post of this thread (and with the workflow).

 

Thank you very much for following through on this issue with me; I really appreciate it. Just one final question: you mentioned something about a quick list. Could you please let me know how to check which cities are currently stored in my quick list and how to add more cities to this quick list? 

 

If I understand you correctly you're saying that the time for quick list cities will ALWAYS be accurate regardless of whether or not I have recently run a timezone update. Is this correct? Thanks.

No, it's the other way round. The "quicklist" will require updating after DST changes, whereas arbitrary individual lookups will be "live" and should be always accurate.

[parekh]

These instructions are all in the first post of this thread (and with the workflow).

 

No, it's the other way round. The "quicklist" will require updating after DST changes, whereas arbitrary individual lookups will be "live" and should be always accurate.

 

So if I empty my quicklist then I will never have to run any updates? If this is the case, then I think this is the perfect solution for me!

[CarlosNZ]

So if I empty my quicklist then I will never have to run any updates? If this is the case, then I think this is the perfect solution for me!

Well, yes, but that kind of defeats the purpose of the workflow. It is designed to be a super-quick way to look up the times in a bunch of cities that you regularly want to check. The "live" single lookup feature is really just a bonus add-on. It works fine, but it's a whole lot slower than the saved quicklist cities.

 

But sure, if that's what you want to do, then go right ahead.

[parekh]

Well, yes, but that kind of defeats the purpose of the workflow. It is designed to be a super-quick way to look up the times in a bunch of cities that you regularly want to check. The "live" single lookup feature is really just a bonus add-on. It works fine, but it's a whole lot slower than the saved quicklist cities.

 

But sure, if that's what you want to do, then go right ahead.

 

Yes, I realize that this is not the way in which you intended for the workflow to be used, but I think that it suits me quite well. I am uncomfortable with the quick list, because it requires me to always ask myself the question "has the timezone in this city changed since the last time I ran a timezone update?" and I don't want to think about this question every time I use the workflow.

 

For what it's worth, I don't think this is your fault, and I still believe that this is an excellent workflow. The real culprit in my mind is the whole concept of Daylight Saving Time, which I find to be outdated and unnecessarily complex for today's global and interconnected world.  

[rice.shawn]

The real culprit in my mind is the whole concept of Daylight Saving Time, which I find to be outdated and unnecessarily complex for today's global and interconnected world.  

 

It is weird, but it's so ingrained that it's hard to remove. It's like names: I live in NYC and everyone knows where the Triboro bridge is, except that it doesn't exist anymore because it was renamed the Robert F Kennedy Bridge six years ago. When I mentioned this to New Yorkers, they have no idea and will still refer to it as the Triboro bridge.

 

The main upshot about DST is that it helps move regular business hours in line with seasonal light levels, which does have an effect that it conserves some energy usage. The other great thing is that once a year, the bars get to stay open an extra hour in the US. It's always a magical weekend. Everything else about it sucks.

 

Anyway, adding accounting information for DST might be fairly hard in bash, but I do know that PHP has some great built-in functions to detect DST. A fix might be to use PHP to check for DST and adjust accordingly. The drawback is that it will make the workflow's performance suffer a bit.

[CarlosNZ]

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?

 

I've finally got round to addressing this. The city list will now always display the results in the same order. (I just removed the "uid" parameter.) Updated version 1.7 now available for download from the first post.

[ericb]

CarlosNZ this plug in is so useful! Thank you for creating it and maintaining it.

 

There is one feature that I'd find extreamly helpful. The ability to specify the time. I work with people from all around the world and when setting up meetings it would be nice to enter somethign like, "tz 18:00", and see what time that would be for all the locations in my default list. 

 

Eric

 

 

 

[CarlosNZ]

CarlosNZ this plug in is so useful! Thank you for creating it and maintaining it.

 

There is one feature that I'd find extreamly helpful. The ability to specify the time. I work with people from all around the world and when setting up meetings it would be nice to enter somethign like, "tz 18:00", and see what time that would be for all the locations in my default list. 

 

Eric

That's a great idea. I've been wanting to try and implement something like this, so I'll definitely look into it. Just need to find some spare time.

[ericb]

That's a great idea. I've been wanting to try and implement something like this, so I'll definitely look into it. Just need to find some spare time.

 

Thanks for considering the request.

 

I've implemented a prototype (source, screenshot). Needs clean up for sure. For example, to support adding a time after tz I broke the new city after tz feature.

 

Eric

[rspike12]

Is there a way to write the time in a different way like 16:00 instead of 4:00PM?

[CarlosNZ]

Is there a way to write the time in a different way like 16:00 instead of 4:00PM?

 

Yes, but you'll need to manually edit the code, if you're cool with that.

 

In the workflow folder (right-click in the workflow list, select "Show in Finder"), open up the file 'timezone_list.sh' in a text editor.

 

Look for these two lines near the top (line 29-30):

city_time=$(date -u -j -f %s $city_epochtime +"%l:%M %p") #Create readable time expression
city_date=$(date -u -j -f %s $city_epochtime +"%A %e %B %Y") #Create readable date expression

Then just change the time exprssion (in quote) to what you want, according to this formatting.

 

So, to get 16:00 instead of 4:00PM, you would make the first line:

city_time=$(date -u -j -f %s $city_epochtime +"%H:%M %p") #Create readable time expression

Hope that helps.

 

(NB: There is another version of these lines near the bottom, which applies to custom lookups.)

[CarlosNZ]

+1

 

Would be nice a new command on the workflow for setting up the time format.

Yes, good idea. I'll try and implement something like this when I next do an update. (Might not be for a while, pretty busy at the moment.)

 

In the meantime, the instructions for manually setting it to 24h display are above: http://www.alfredforum.com/topic/491-timezones-a-world-clock-script-filter-updated-to-v17/?p=29339

 

Cheers,

Carl.

[mrgreen]

CarlosNZ this plug in is so useful! Thank you for creating it and maintaining it.

 

There is one feature that I'd find extreamly helpful. The ability to specify the time. I work with people from all around the world and when setting up meetings it would be nice to enter somethign like, "tz 18:00", and see what time that would be for all the locations in my default list. 

 

Eric

 

That idea is exactly what led me to this thread!

 

Plus you can add the functionality 

Let's say, I have an appointment at 7pm Hong Kong time, then I would type in:

tz Hong Kong 19:00

tz Kong Kong 7pm

...

 

-> output would current time in my time zone + time in cities in list.

 

PS: if you are really bad ass, add a function to directly create an event in calendar app at this time by pressing e.g. CMD+ENTER

 

#valuebomb

[effe]

Put this thing on Github!

I added a simple sort to the time zone list based on the UTC. within the same UTC it sorts alphabetically.

just added a call to a short one liner script I made ( sortCities.sh below ) in add_city.sh right before the last echo

. ./sortCities.sh "$timezone_file"

sortCities.sh

#!/bin/bash
sed 's/UTC//g' "$1" | sed 's/+//g' | sort -t '|' -ngk 9,9 | sed 's/|/|UTC+/8' | sed 's/+-/-/1' > "$1" 2>&1

edit:

 

Monkeyed around with it a bit more, and implemented a simple hour offset addition from your current timezone.

 

added:

 

calc.sh # from ( http://www.novell.com/coolsolutions/tools/17043.html )

#!/bin/bash
echo "scale=1; $1" | bc;exit;

getOffsetFromCurrentTimeZone.sh # from me

#!/bin/bash
timeZoneIn=$(echo "$1" | bc)
utcData="$(date +%z | sed 's/+//g' | bc)"
diff=$( . ./calc.sh "$timeZoneIn - $utcData" )
echo "$diff"

and then in timezone_list.sh modified near the echo items statements:

[...]
            utcOffset=$(echo "$display_offset" | sed 's/UTC//g' | sed 's/+//g')
            utcOffset=$( . ./calc.sh "$utcOffset * 100" )
            utcVal=$( . ./getOffsetFromCurrentTimeZone.sh $utcOffset )
            utcVal=$( . ./calc.sh "$utcVal / 100" )
            utcVal=" $utcVal hours away "

        echo '<item arg="'$city_returned'|'$city_time'|'$city_date'|'$country'|'$tz_name'|'$display_offset'" valid="yes">
        <title>'$city_returned: $city_time'</title>    
        <subtitle>on '$city_date'  •  '$country' • '$tz_name' ('$display_offset') • ('$utcVal')</subtitle>
        <icon>./flags/'$flag_icon'</icon>
        </item>'


[...]


        utcOffset=$(echo "$display_offset" | sed 's/UTC//g' | sed 's/+//g')
        utcOffset=$( . ./calc.sh "$utcOffset * 100" )
        utcVal=$( . ./getOffsetFromCurrentTimeZone.sh $utcOffset )
        utcVal=$( . ./calc.sh "$utcVal / 100" )
        utcVal=" $utcVal hours away "

    echo '<item uid="custom" arg="'$city_returned'|'$city_time'|'$city_date'|'$country'|'$tz_name'|'$display_offset'" valid="yes">
        <title>'$city_returned: $city_time'</title>    
        <subtitle>on '$city_date'  •  '$country' • '$tz_name' ('$display_offset') • ('$utcVal')</subtitle>
        <icon>./flags/'$flag_icon'</icon>
        </item>'
[...]

also, I had to modify one of the if statements in timezone_list.sh because the comparison didn't like decimal numbers( some timezones with .5 hour offsets ):

.. instead of comparing, just replace double sign if it's there.

    display_offset="UTC+$UTC_offset"
    display_offset=$( echo "$display_offset" | sed 's/+-/-/g')

Edited April 20, 2015 by effe

[chiefted]

Outstanding work flow. For folks whose work includes multiple offices in multiple time zones this is a must have. 

[Kevllar]

Anybody else have issues using this workflow behind a proxy? 
 
Any new cities I query can't seem to fetch the data. "Sorry... No matches for Toronto"
 
Which seems pretty odd. Doesn't work with any other city either. 
 
I've allowed Alfred to use the system proxy settings in Advanced but no luck... Any ideas?

 

My proxy settings point to a http://wpad/wpad.dat

[joncrooke]

Great workflow, but personally I'd find displaying a local time offset (rather than UTC offset) much more useful. Also, a feature for 'tz time in <place> at <local time>' would be great for scheduling international phone calls.

[CarlosNZ]

Great workflow, but personally I'd find displaying a local time offset (rather than UTC offset) much more useful. Also, a feature for 'tz time in <place> at <local time>' would be great for scheduling international phone calls.

That's a good point, and something that has been asked before. I'll add it to my TO DO list. (Hopefully I'll get some time soon...)

 

Thanks for your feedback.

[likufanele]

Any way to easily get this to output 24 hour time?

[CarlosNZ]

Any way to easily get this to output 24 hour time?

 

If you are happy to make a little manual edit to the script file:

 

http://www.alfredforum.com/topic/491-timezones-a-world-clock-script-filter-updated-to-v17/?p=7761

[CarlosNZ]

Hey, made a tiny update to incorporate a new 256px icon. No other changes (at this point).

 

http://bit.ly/timezones-1-7a

[paulw]

Hi Carlos, Thanks for your workflow. I saw a little discussion about DST in the posts. Any chance you'll add that? For instance, it says it's 10:30pm here in New York, but it's 9:30pm.

 

Paul