Tempo Date Format

[K Ericsson]

Am I the only person in the USA who has noticed that the date format on tempo time sheets is wrong?  Perhaps my employer is the only one in the USA to use this UK-based tool.

My profile is set up for ENGLISH UNITED STATES.  

So the dates should show as MM/DD.

However, on the tempo timesheet, the dates are displaying as DD.MM instead of MM/DD. For example, today is May 9. The date should show as 05/09. Instead, it shows as 09.05, which makes me think it is September 5.

This is very confusing, as this is not the USA format for dates.

We have had TWO releases of this product, and STILL, the bug is not fixed.

I welcome people from the UK to try looking at dates as MM/DD for TWO YEARS EVERY SINGLE DAY and see how THEY like it.

Please, please PLEASE, FIX THE DATE FORMAT.

[K Ericsson]

The answer is to FIX THE BUG.  Not in four years, but NOW.

[bgunn]

This has been driving me crazy for YEARS! I keep looking for some setting to fix it, but none exists. This is ridiculous that this is just a bug that's existed for this long, especially since bugs for this were filed nearly 6 years ago, with a fix promised 5 years ago!

Please, please, please fix this!

I'm a developer, so I'm guessing this is just one of those bugs that's really easy to fix, but seen as a low priority because of how it doesn't crash the app or destroy data or anything. But it's insanely annoying. As the OP suggests, have the people in UK try to switch to US format and they'll see very quickly how critical this "non-critical" bugfix is.

[K Ericsson]

Thank you for your support, bgunn.  

[Deleted user]

I am getting complaints from my users as well.  

[K Ericsson]

Thank you for your support, Debbie Jones.

[Rich Scire]

We just migrated to the cloud last weekend and I noticed it and I'm getting user complaints also.

[Josh Soref]

So, having cursed this plugin for 5 years, I finally took the time to figure out what it was doing and how to do something about it.

1. Make a directory to host our fixed script:

mkdir /var/www/jira-fixups

2. Retrieve your current version of the script, it'll be something like this (use your favorite web browser to find the equivalent url or check your web server's logs):

curl 'http://127.0.0.1:8090/s/d41d8cd98f00b204e9800998ecf8427e-CDN/-k6js55/73011/b6b48b2829824b869586ac216d119363/8.7.0/_/download/batch/is.origo.jira.tempo-plugin:tempo-smartsheet/is.origo.jira.tempo-plugin:tempo-smartsheet.js' > /var/www/jira-fixups/tempo-smartsheet.js

3. Replace the annoying code with something less annoying:

perl -pi -e 's{"MM.DD":"DD.MM"}{"MMM DD":"MMM DD"}' /var/www/jira-fixups/tempo-smartsheet.js

Note: by fixing it this way, I don't have to care about whether some of my users actually like DD.MM behavior, none of my users will have *any* problem parsing MMM DD.

This assumes you're using Apache 2.4 and it's using mod_proxy of some sort to connect to your Jira install:

4. Tell Apache not to send queries for this file to Jira, instead.

Insert this:

ProxyPassMatch "tempo-smartsheet.js" !
ScriptAliasMatch "^.*tempo-smartsheet.js$" "/var/www/jira-fixups/tempo-smartsheet.js"

Before:

ProxyPass / http://127.0.0.1:8090/ retry=0

Or whatever your equivalent thing is.

It should be fairly easy for people to adapt this last little bit to suit their proxy environment.