Jump to content
CarlosNZ

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

Recommended Posts

Is there a way to sort the list in order of current time instead of alphabetically? The current listing doesn't work the way my mind thinks.

 

Manually editing the list to my preferred order doesn't seem to work, but I'm open to other workarounds.

Share this post


Link to post

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

Share this post


Link to post

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.

Screen Shot 2019-08-22 at 9.31.23 AM_shrink.png

Screen Shot 2019-08-22 at 9.31.13 AM_shrink.png

Share this post


Link to post
Posted (edited)
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 ?1372724495_ScreenShot2019-08-22at10_10_57.png.ac3cd0b8a12c5e6bb4dbf607eb134b66.png
 

Edited by drwatson

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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!!!

 

Share this post


Link to post

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 ?

Share this post


Link to post
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

 

Share this post


Link to post
Posted (edited)
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 by drwatson

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post
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 🙂

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...