Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bag roast date not taking into account different date formats #111

Open
aarongoldenthal opened this issue Sep 22, 2024 · 3 comments
Open
Labels
bug Something isn't working enhancement New feature or request

Comments

@aarongoldenthal
Copy link

aarongoldenthal commented Sep 22, 2024

Describe the bug

I have the date format setting for the DYE extension set to MDY. My most recent bag is entered as 09.02.2024 (i.e. September 2, 2024), and the extension is interpreting it correctly since it says is 19 days off roast. The visualizer, on the shot and roasters pages, now displays the roast date, but it's showing as February 09, 2024. So, if the date parses it's incorrect, but many dates will fail to parse properly.

To Reproduce
Steps to reproduce the behavior:

  1. Enter bag roast date with the DYE extensions set to MDY (and maybe anything other than DMY, I did not check) and upload a shot
  2. Check the date displayed for the shot

Expected behavior

The date format should be taken into account when parsing dates.

Desktop (please complete the following information):

  • OS: Windows 11
  • Browser: Chrome 129.0.6668.59
@miharekar
Copy link
Owner

Ah, interesting. Need to look into how DYE handles this and if there's a way for me to detect which one it is 🤔

@miharekar miharekar added the bug Something isn't working label Sep 23, 2024
@miharekar
Copy link
Owner

miharekar commented Sep 23, 2024

Just checked with @ebengoechea and:

…the setting to format it as the user wants is a DYE setting, not a global setting you can find in the file

I think the app would handle dates with numbers larger than 12 on the second position automatically, but it can't determine what "09.02.2024" stands for since it's ambiguous. It assumes it's not MDY since, as far as I know, that's only used in 1 out of 195 countries in the world 😂

I will need to add a setting for this I believe. Similar to Fahrenheit. Huh, maybe I could even use that, since that's also not used much outside of USA. 😅

@miharekar miharekar added the enhancement New feature or request label Sep 23, 2024
@aarongoldenthal
Copy link
Author

aarongoldenthal commented Sep 23, 2024

I think the app would handle dates with numbers larger than 12 on the second position automatically, but it can't determine what "09.02.2024" stands for since it's ambiguous. It assumes it's not MDY since, as far as I know, that's only used in 1 out of 195 countries in the world 😂

True, but it is the first option 😉. Obviously an easy fix is just to change formats, which is what I'm going to do for now.

FYI - Changing the bag date first in the visualizer updated everything, that's really nice, and then the next shot (now DMY) synced with the previous bag by date.

I will need to add a setting for this I believe. Similar to Fahrenheit. Huh, maybe I could even use that, since that's also not used much outside of USA. 😅

Is it weird that I use US date format and Celsius 🤣.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants