Date Tools

[akrabat]

I'd like to submit my Date Tools workflow to the Alfred Gallery if it's acceptable.

 

I am the author and the link to it's Alfred Forum thread is: https://www.alfredforum.com/topic/20224-simple-date-tools/

 

It's published on GitHub at https://github.com/akrabat/alfred-date-tools and it depends on Homebrew's coreutils package.

 

It provides two keyword filters: dn to display the day number for the provided date and isleapyear to show if the provided year is a leap year or not:

 

 

I'm a little unclear how I should format the GitHub repository. Currently, it's a direct check in of the workflow directory from Alfred's workflows directory. Is this correct?

 

[vitor]

In general it would be best to use the date utility which ships with macOS, but that doesn’t affect the submission.

However, I’ve found a few funky behaviours:

• dn is set to Argument Optional, instead of Argument Required.
• dn parses numbers weirdly. E.g. dn 19 makes it show the 9th day.
• isleapyear parses numbers weirdly. Numbers with 1, 3, 4, or more digits show the correct year, but numbers with two digits map to the 2000’s. Either 1 and 3 digits should consistently map to the 2000’s, or 2 digits should show the corresponding year.

 

2 hours ago, akrabat said:

I'm a little unclear how I should format the GitHub repository. Currently, it's a direct check in of the workflow directory from Alfred's workflows directory. Is this correct?

 

Yes, that works fine. As long as you use the Releases feature consistently to release new versions, they can be detected.

[akrabat]

Vitor,

 

Thanks for the feedback. it's always interesting when someone else uses your stuff differently

 

16 hours ago, vitor said:

In general it would be best to use the date utility which ships with macOS, but that doesn’t affect the submission.

Unfortunately, BSD's date doesn't suppose the variety of formats that GNU's does. e.g.  gdate -d "last monday" is possible, but there's no equivalent in the BSD date. 

Now that PHP no longer ships with macOS, none of the built-in scripting languages have an out of the box string-to-date parser provided with the OS. Testing a Python implementation using the dateparser library , it's over 100 times slower than the gdate version though and causes a noticeable pause when running the workflow.
 

I'm not sure it's worth providing a fall back to Python if gdate isn't installed to remove the dependency requirement at the expense of shipping a bigger workflow?
 

16 hours ago, vitor said:

However, I’ve found a few funky behaviours:

• dn is set to Argument Optional, instead of Argument Required.

 

I usually use dn with no argument and it will use today's date. I think that I need Argument Optional to make this behaviour work? My most common uses are dn and dn last tuesday (or whatever day I need). 

 

16 hours ago, vitor said:

• dn parses numbers weirdly. E.g. dn 19 makes it show the 9th day.

Good catch. It seems that 19 is interpreted by gdate as "19:00 on today's date", hence yesterday it used "9th April 2023" for its calculations.

I'm not sure there's much I can do about this. Python's dateparser library interprets, "19" as "19 April 2023", but "1" as "10th January 2023"! Arguably that's more confusing. 

I've fixed this by adding a check to ensure that parsing isn't attempted for just numbers, unless there are exactly 8 numbers (e.g. 20230301).

 

16 hours ago, vitor said:

• isleapyear parses numbers weirdly. Numbers with 1, 3, 4, or more digits show the correct year, but numbers with two digits map to the 2000’s. Either 1 and 3 digits should consistently map to the 2000’s, or 2 digits should show the corresponding year.

This is gdate's date parsing trying to be clever with two digit years. Fixed so that a two digit date is now the correct corresponding year.
 

16 hours ago, vitor said:

Yes, that works fine. As long as you use the Releases feature consistently to release new versions, they can be detected.

Do you mean that after I tag and push, I should create a new Release within GitHub and attach a `.workflow` binary by exporting from my install of Alfred? to it? or does the Gallery pick up that the new release exists and creates the workflow binary itself?

v0.9.1 is pushed to GitHub with the fixes for the dn and isleapyear number parsing issues. 

Edited April 10 by akrabat

[vitor]

7 hours ago, akrabat said:

Now that PHP no longer ships with macOS, none of the built-in scripting languages have an out of the box string-to-date parser provided with the OS.

 

/usr/bin/osascript with JavaScript as the language can do it. But as I said, it wouldn’t affect submission. I agree the gdate -d "last monday" and similar justify the use of gdate.

 

7 hours ago, akrabat said:

I usually use dn with no argument and it will use today's date. I think that I need Argument Optional to make this behaviour work?

 

Yes. That is fine, then.

 

7 hours ago, akrabat said:

This is gdate's date parsing trying to be clever with two digit years. Fixed so that a two digit date is now the correct corresponding year.

 

It seems something broke with the update. Now anything I try in inleapyear returns “ is not a leap year”. Without a number. It fails for leap years like 2024.

Also, it seems you inadvertently added a lib folder with a python binary which is not used.

 

7 hours ago, akrabat said:

Do you mean that after I tag and push, I should create a new Release within GitHub and attach a `.workflow` binary by exporting from my install of Alfred?

 

Exactly.

[akrabat]

13 hours ago, vitor said:

It seems something broke with the update. Now anything I try in inleapyear returns “ is not a leap year”. Without a number. It fails for leap years like 2024.

Also, it seems you inadvertently added a lib folder with a python binary which is not used.

Doh. Fixed in 0.9.2

 

13 hours ago, vitor said:

20 hours ago, akrabat said:

Do you mean that after I tag and push, I should create a new Release within GitHub and attach a `.workflow` binary by exporting from my install of Alfred?

 

Exactly.

 

 

Got it. I have plugged in https://github.com/almibarss/build-alfred-workflow to automatically create a Release and attach the .workflow file when I push a new tag. This workflow includes the version number in the generated filename, such as Date-Tools-0.9.2.alfredworkflow. Does this matter?

[vitor]

2 hours ago, akrabat said:

This workflow includes the version number in the generated filename, such as Date-Tools-0.9.2.alfredworkflow. Does this matter?

 

It does not.

 

But now it’s also including the .git, .gitignore, and .github in the workflow.

[akrabat]

8 hours ago, vitor said:

But now it’s also including the .git, .gitignore, and .github in the workflow.

 

That'll teach me to assume that the workflow would do the obvious thing!

Fixed in 0.9.3 at https://github.com/akrabat/alfred-date-tools/releases/tag/0.9.3

 

[vitor]

Thank you for the changes. This will be live soon at https://alfred.app/workflows/akrabat/date-tools/.

 

Edited April 13 by vitor