Jump to content

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


Recommended Posts

  • 4 weeks later...
  • Replies 193
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Here's another little tool I've just whipped up:   Get an instant list of the current time in various cities around the world. Which you can customize, of course.   Main keyword: tz (for TimeZon

In fact, 24h format has been hardcoded into version I've tailored from CarlosNS' version. This has been updated in v1.9 which can be downloaded from http://jhartman.pl/download/alfred-timezone-workflo

Bloody hell. That was fast!

Posted Images

  • 3 months later...

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

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

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.

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

 

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

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

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.

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.

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

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?

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.

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

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.

Link to post

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

Link to post

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