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

Date localization not working on custom fields #8143

Closed
2 tasks done
pdklein88 opened this issue Jun 17, 2020 · 12 comments · Fixed by #10804
Closed
2 tasks done

Date localization not working on custom fields #8143

pdklein88 opened this issue Jun 17, 2020 · 12 comments · Fixed by #10804
Assignees

Comments

@pdklein88
Copy link

pdklein88 commented Jun 17, 2020

Please confirm you have done the following before posting your bug report:

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

  1. Create custom field in Settings > Custom Fields
  2. Set format to DATE
  3. Edit the asset and set the date field

Expected behavior
Date field should show proper format as selected in Localization page. Purchase date is a standard field that works as expected.

Screenshots
I can't figure out how to upload a screenshot, so I'll retype what I am seeing:

Last Annual Maintenance 2019-09-13
Purchase Date 08/08/2018

Is this a fresh install or an upgrade? Fresh
Version of Snipe-IT you're running 4.9.2 build 4352
Version of PHP you're running 7.3.19
Version of MySQL/MariaDB you're running
What OS and web server you're running Snipe-IT on Windows Server 2019

@UserGoodtm
Copy link

The screenshot (file) is simply dragged into the message body

@stale
Copy link

stale bot commented Aug 16, 2020

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

@stale stale bot added the stale label Aug 16, 2020
@pdklein88
Copy link
Author

pdklein88 commented Aug 17, 2020 via email

@stale
Copy link

stale bot commented Aug 17, 2020

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

@stale stale bot removed the stale label Aug 17, 2020
@stale
Copy link

stale bot commented Dec 25, 2020

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

@stale stale bot added the stale label Dec 25, 2020
@kamlot-it
Copy link

kamlot-it commented May 17, 2021

I'll try to drop it here as I have this problem also:

Custom field name: Warranty ends

Chosen format on /admin/localization:
image
Display format on Asset page:
image

Custom Fields configuration view:
image

Issue still persists on v. 5.1.5 - build 6055
PHP: v. 7.4.3
OS: Ubuntu 20.04
MySQL: v. 8.0.25

@stale
Copy link

stale bot commented May 17, 2021

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

@stale stale bot removed the stale label May 17, 2021
@dg-td
Copy link

dg-td commented Mar 8, 2022

We are seeing this as well. Snipe-IT v5.4.1 - build 6746.
Ubuntu 20.04, PHP 7.4.3, Apache 2.4.41, MariaDB 10.3.32.

We have "Ship Date/Warranty Start" and "Warranty End" custom fields with the format set to DATE. In Localization settings, "Time and Date Display" is set to mm/dd/yyyy.

Here's an example when viewing an asset:

Ship Date/Warranty Start 2019-08-11
Warranty End 2022-08-11
Purchase Date 08/08/2019

@inietov
Copy link
Collaborator

inietov commented Mar 9, 2022

Looks like a common problem... Let me see what I can do.

@inietov inietov self-assigned this Mar 9, 2022
snipe added a commit that referenced this issue Mar 9, 2022
…rking_custom_fields_develop

Fixes #8143 Date localization not work in custom fields for develop branch
snipe added a commit that referenced this issue Mar 9, 2022
…rking_custom_fields

Fixes #8143 Date localization not work in custom fields
@dg-td
Copy link

dg-td commented Apr 12, 2022

In Snipe-IT v5.4.2 this bug has been fixed in some places but not others.

We have "Ship Date/Warranty Start" and "Warranty End" custom date fields. In Localization settings, we have "Time and Date Display" set to mm/dd/yyyy.

If you view an asset and look in the Info tab, the custom fields now show up correctly, as mm/dd/yyyy, as of Snipe-IT v5.4.2. See the screenshot below. In v5.4.1 and earlier, before the bug fix, they showed up incorrectly as yyyy-mm-dd.

snipe-it-asset-detail

If you go to the Dashboard and click the "total assets" button, and then search for assets, the custom fields still show up incorrectly as yyyy-mm-dd. See the screenshot below, where the two fields are shown next to a standard (non-custom) field, Purchase Date.

snipe-it-asset-search

We are running Snipe-IT on Ubuntu 20.04, with PHP 7.4.3 and Apache 2.4.41.

@dg-td
Copy link

dg-td commented May 27, 2022

This is still a problem in v6.0.2. I went to demo.snipeitapp.com and created a custom date field called TestCustomDateField, and entered a date for one laptop.

In Dashboard -> Assets button -> view all, the date shows up incorrectly in the table in yyyy-mm-dd format. It doesn't match the format set in "Time and Date Display" in the Localization settings. Here is a screenshot with the date circled:

All Assets

If you click on the Asset Tag to go to the "View Asset" page, the format is correct. It matches the format set in the Localization settings. The update in v5.4.2 fixed the date format here, but not in the "All Assets" list as shown above.

View Asset

@inietov
Copy link
Collaborator

inietov commented Jun 7, 2022

Thanks for the heads up @dg-td. I overlooked it in my first attempt... but that's why the community is so important. I think now it's good to go. Thanks again!!

@snipe snipe closed this as completed in 20a0c4e Jun 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants