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

Recommended Posts

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.

Share this post

Link to post

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.

Share this post

Link to post

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

Share this post

Link to post

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.

Share this post

Link to post

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.

Share this post

Link to post

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.

Share this post

Link to post

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.

Share this post

Link to post

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.

Share this post

Link to post

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

Share this post

Link to post

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.

Share this post

Link to post

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

Share this post

Link to post

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.

Share this post

Link to post

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...)