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

[RPBarnes]

Thx for this workflow! I am new to Alfred and workflows, however, this is the first one to be added. Brilliant  Regards, Richard.

[Jarek]

Hi,

 

Latest version can be downloaded from:

• https://github.com/jaroslawhartman/TimeZones-Alfred
• https://jhartman.pl/tag/alfred/
• http://www.packal.org/workflow/timezones-2

At time of writing, v2.6 is the latest.

 

Best regards,

Jarek

[aein]

Hi! I love this workflow, thank you for making it.

 

I'm having a problem with some cities.  "tz los angeles 5am" works great, but when I use some other city names like turin, it does not work.

I've attached screenshots.

[drwatson]

26 minutes ago, aein said:

Hi! I love this workflow, thank you for making it.

 

I'm having a problem with some cities.  "tz los angeles 5am" works great, but when I use some other city names like turin, it does not work.

I've attached screenshots.

 

 

I don't get what you're trying to do or what the problem is. Are you trying to get it to highlight the right one ?

My version ( 2.0 ) will only show the matching results. Maybe you could upgrade ?
 

Edited August 22, 2019 by drwatson

[drwatson]

Looks like 2.12 is the latest: https://github.com/jaroslawhartman/TimeZones-Alfred/releases/tag/v2.12

[Tonycr46]

I'm also having trouble with the sort order. I have the txt file ordered as I would like them to appear but, with the result order disabled, they come up seemingly random. With the result order enabled, I get order that I have on the list but starting with the 3rd entry and, at the end of the list, wrapping to the 1st and 2nd.

 

Thoughts?

[deanishe]

2 hours ago, Tonycr46 said:

Thoughts?

 

The problem is this line.

Bash interprets numbers with leading zeroes as being in octal, so it throws an error if you have more than 7 timezones and resets the sort count to zero.

That line should be sortkey=$(printf "%03d" $(( 10#$sortkey + 1 )))

The 10# tells bash to interpret the numbers in base 10.

[Jarek]

17 minutes ago, deanishe said:

That line should be sortkey=$(printf "%03d" $(( 10#$sortkey + 1 )))

The 10# tells bash to interpret the numbers in base 10.

 

Thank you for troubleshooting and suggesting a fix. I've included it in the branch and released v2.13 

It can be downloaded from https://github.com/jaroslawhartman/TimeZones-Alfred/releases

 

Best regards,

Jarek

[deanishe]

1 minute ago, Jarek said:

I've included it in the branch and released v2.13

 

Bloody hell. That was fast!

[Tonycr46]

7 minutes ago, deanishe said:

 

Bloody hell. That was fast!

 

I'll say. Within 3 hours we have a trouble analysis and a fix posted! Kudos to @deanishe and @Jarek!!!

 

[drwatson]

Jarek: I noticed that the workflow doesn't save the timezone.txt file to the correct location anymore. Any chance you could look into that ?

[Jarek]

6 minutes ago, drwatson said:

Jarek: I noticed that the workflow doesn't save the timezone.txt file to the correct location anymore. Any chance you could look into that ?

 

Could you please elaborate what do you mean by correct location?

Indeed, there was a change a few releases back and it was related to Alfred 4. Instead of having a hardcoded path,  it uses now alfred_workflow_data variable.

 

On my Mac it's /Users/jhartman/Library/Application Support/Alfred 3/Workflow Data/carlosnz.timezones2:

jhartman$ cd "/Users/jhartman/Library/Application Support/Alfred 3/Workflow Data/carlosnz.timezones2"
jhartman$ ls -l
total 16
-rw-r--r--@ 1 jhartman  staff   26 Aug 14 14:48 configExtra
-rw-r--r--  1 jhartman  staff  369 Aug 14 15:04 timezones.txt

Best regards,

Jarek

 

[drwatson]

7 minutes ago, Jarek said:

 

Could you please elaborate what do you mean by correct location?

Indeed, there was a change a few releases back and it was related to Alfred 4. Instead of having a hardcoded path,  it uses now alfred_workflow_data variable.

 

On my Mac it's /Users/jhartman/Library/Application Support/Alfred 3/Workflow Data/carlosnz.timezones2:

 

There have been two possible factors that determine the location of timezone.txt:

 

1. The preference folder as determined in Advanced | Set preferences folder
2. The storage location as defined within the timezone script itself (timezone move command).

 

Right now, it doesn't appear to honor either

Edited August 26, 2019 by drwatson

[Jarek]

7 minutes ago, drwatson said:

1. The preference folder as determined in Advanced | Set preferences folder
2. The storage location as defined within the timezone script itself (timezone move command).

Right now, it doesn't appear to honor either

 

I think the (1) still works, as the location set by Set Preferences Folder should be reflected as $alfred_workflow_data variable (which is in use).

 

Indeed, there is a regression in (2) - the Move command does not work anymore. Registered as https://github.com/jaroslawhartman/TimeZones-Alfred/issues/23 . Will try to prioritise.

 

Best regards,

Jarek

[drwatson]

1 minute ago, Jarek said:

 

I think the (1) still works, as the location set by Set Preferences Folder should be reflected as $alfred_workflow_data variable (which is in use).

 

 

I changed to latest version but ended up rolling back to 2.0 because neither seemed to work. I don't think preferences folder has ever worked tbh which is why I was using the move command to begin with.

 

Thanks for prioritizing !

 

-d

[Jarek]

I think I understand what is happening. I still don't understand why... Posted a query to Alfred, but I'm thinking of a workaround regardless of their answer.

 

Best regards,
Jarek

[drwatson]

18 minutes ago, Jarek said:

I think I understand what is happening. I still don't understand why... Posted a query to Alfred, but I'm thinking of a workaround regardless of their answer.

 

Best regards,
Jarek

 

It looks like other workflows store data in the info.plist file. What if the data is stored there instead? THen you can rid of the timezone move command altogether?

Also, if you still want to keep it for backwards compatability, you could use the info.plist to store a reference to the location of the file instead.

[Jarek]

7 minutes ago, drwatson said:

Also, if you still want to keep it for backwards compatability, you could use the info.plist to store a reference to the location of the file instead.

 

That's exactly the workaround I was thinking of 🙂

[deanishe]

4 hours ago, Jarek said:

I think the (1) still works, as the location set by Set Preferences Folder should be reflected as $alfred_workflow_data variable (which is in use).

 

That's incorrect. The Preferences Folder does not contain workflow data or cache. This is very deliberate. $alfred_workflow_data and $alfred_workflow_cache point to directories in ~/Library/Application Support and ~/Library/Caches respectively.

Previous to Alfred 4, there were different directories for every version of Alfred. Alfred 4 and all later version should use the same directories.

 

3 hours ago, Jarek said:

That's exactly the workaround I was thinking of 🙂

 

Don't put the data in info.plist (unless you correctly store them as workflow variables). They'll be overwritten on update otherwise. Same goes for any files you store in the workflow folder.

Save the file in $alfred_workflow_data, like you're supposed to. As noted above, this will never change again.

[Jarek]

52 minutes ago, deanishe said:

Save the file in $alfred_workflow_data, like you're supposed to. As noted above, this will never change again.

 

The script is using this variable even now. Problem with this setup is that there is no link between value of this variable and your Advanced | Set preferences folder . I was assuming that once changing the preference folder, the $alfred_workflow_datawill be also changed - but it's not. My bad, will need to rectify it.

 

Best regards,

Jarek

[deanishe]

2 hours ago, Jarek said:

I was assuming that once changing the preference folder, the $alfred_workflow_datawill be also changed - but it's not

 

Indeed it's not. It has never worked that way. I explained a workaround in your bug report (although it's not a bug) if you really must keep some data in the preferences bundle.

 

But this hasn't really been a problem for anyone before, so is your workflow really that special?

[drwatson]

7 hours ago, deanishe said:

 

But this hasn't really been a problem for anyone before, so is your workflow really that special?

 

this seems like an unnecessary question. If I had to guess, it's because Jerek inherited the code from someone else. He's done a great job.  I'd leave it at that.

[Jarek]

13 hours ago, deanishe said:

But this hasn't really been a problem for anyone before, so is your workflow really that special?

 

6 hours ago, drwatson said:

 

this seems like an unnecessary question. If I had to guess, it's because Jarek inherited the code from someone else. He's done a great job.  I'd leave it at that.

 

I don't take it personally. I don't think this workflow is special in any way. But it was even admitted in your response to mu question, that there are no official guidelines how to treat workflow preferences to make them mobile across different devices. However, I like the suggestion provided there, will try to implement.

 

Best regards,

Jarek

[deanishe]

6 hours ago, drwatson said:

He's done a great job.

 

He has, and it's a great workflow. I'm not criticising the workflow.

 

When I ask, "Is your workflow really that special?", I'm asking if the workflow is so special that it needs to not follow the rules. Is the added functionality worth the potential hassle of additional support and maintenance? Is it so popular that Andrew would avoid making changes to Alfred that might interfere with its non-standard behaviour?

 

The standard way might not be optimal for your particular use case, but you should always have a very good reason for not following the standard because of the problems that might cause for users and yourself.

 

It's a very extreme example, but look at all the trouble caused by Node-based workflows because the Node guys didn't want to build and install their workflows the normal way. Users have a lot of problems with those workflows, and their developers in turn spend a lot of time helping those users.

[Tonycr46]

Being the OP for this part of the thread, the discussion has gone beyond my competence (I just want the final workflow 😀). Just let me know when the dust settles and we are at a stable product. 👏

 

Thanks to all for your efforts in hashing this out. Didn't know I was opening a can of worms. 🥫

 

(I think that's 2 more emojis than I've ever used in one message before.)