The time zone is configured correctly, but only the time is correct, and the date does not change anyway

[zhouxinjx]

Debug mode

• I have enabled debug mode
• I have read checked the Common Issues page

Describe the bug

Configure the time zone supported by PHP according to the document, but the time is correct, the date is fixed on July 25th, and the time will change when modified to other time zones, but the date remains unchanged.

Reproduction steps

1.vim .env
2.APP_TIMEZONE='Asia/Shanghai'
3.
...

Expected behavior

After modifying the time zone of the .env file, the time and date should match the system time.

Screenshots

Snipe-IT Version

6.1.2

Operating System

Centos7

Web Server

Apache 2.4.6

PHP Version

7.4.33

Operating System

Windows

Browser

Edge

Version

115.0.1901.183

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

启用调试后，如果您在浏览器中遇到错误，请包含该错误 如果错误中提供了堆栈跟踪，请也包括该错误
。
浏览器错误控制台中显示的任何错误。
确认错误在演示中是否可重现：https://snipeitapp.com/demo。
包括您可以在 Web 服务器日志中找到的任何其他信息。
包括来自的输出（这应该显示您已启用的模块。storage/logsphp -m

Additional context

1.Clean installation
2.Cenos7 and Apache
3.install.sh
4.No errors were received
5.There is no direct editing of the database

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

[zhouxinjx]

It seems to be a display problem, I tried to create a new user later, and the user's creation time was correct.

[inietov]

I think that is expected behavior, that time is just an example of how the current format would look. @snipe you think that we need to change it to current time so it's less confusing?

[zhouxinjx]

Thanks for your help, I installed Snipe-IT on the 25th, so I didn't find this to be just an example at the time, so I felt that this should be noted in particular.

[snipe]

@zhouxinjx As I mentioned in @inietov's pull request:

In my original localization PR that added this UI setting, I specifically decided to use 25 so that more confusing date formats would be clearer. For example, 03-02-2023 could mean March 2, 2023 or February 3, 2023, depending on how you’re used to seeing dates. Since 25 isn’t a valid number for a month, it makes it clearer versus using the current day of the month, IMHO, but am open to being convinced otherwise.

[zhouxinjx]

Thank you for your reply, if there is a user who happens to install on the 25th, since the time display is correct, then we will think that the date should also be correct, by the 26th we are confused, I even think that I installed the wrong one.

[snipe]

The date is just an example so you see what a date would look like in that format. It only affects the display of when dates are shown elsewhere.

[zhouxinjx]

Now I can understand what you're doing, but I've seen some people on the web who share my confusion and want to illustrate that in that interface.

[snipe]

I think it would be more confusing if we changed the behavior though, for the reasons I mentioned before. Feb 2, 2023 would look like 02-02-2023 (mm-dd-yyyy) and 02-02-2023 (dd-mm-yyyy) so you wouldn't know what format you're actually picking.

[zhouxinjx]

I'm sorry, I really didn't notice this, but your approach is correct in comparison, but the question I raised has also caused some people to be troubled, and we should think of a way to have it both ways.

[snipe]

I don't think I've ever seen anyone else get confused by the date selector before and I've been working on this project for a decade, so I'm not sure this would be one of our highest priorities. Shipping v7 is the biggest priority right now.

[zhouxinjx]

Ok, anyway, I would like to thank you two for helping me answer the question.

[snipe]

Of course. It's possible we can make this clearer in the UI to avoid any confusion.