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

DateTime hardcoded format Y-m-d H:i:s drives to "Error converting data type varchar to datetime" #608

Closed
mikeabbott10 opened this issue Jan 23, 2023 · 13 comments
Labels
bug Something isn't working

Comments

@mikeabbott10
Copy link

mikeabbott10 commented Jan 23, 2023

PHP Version

8.1

CodeIgniter4 Version

4.3

Shield Version

1.0.0-beta3

Which operating systems have you tested for this bug?

Windows

Which server did you use?

apache

Database

SQL Server 2019

Did you customize Shield?

No

What happened?

My db language is Italian and expects datetime format like 'd-m-Y H:i:s'. When you attempt to login, it tries to insert a row using the format 'Y-m-d H:i:s' by default and that's hardcoded at Shield\Models\LoginModel row 71.

'date' => Time::now()->format('Y-m-d H:i:s'),

Steps to Reproduce

Connect to a database with a datetime expected format not equal to 'Y-m-d H:i:s' and try to login

Expected Output

The row gets insterted

Anything else?

I think the format has to be customizable without the need to extend the LoginModel and override the whole recordLoginAttempt just for this.

@mikeabbott10 mikeabbott10 added the bug Something isn't working label Jan 23, 2023
@mikeabbott10 mikeabbott10 changed the title Bug: Error converting data type varchar to datetime Bug: date hardcoded format drives to "Error converting data type varchar to datetime" Jan 23, 2023
@mikeabbott10 mikeabbott10 changed the title Bug: date hardcoded format drives to "Error converting data type varchar to datetime" Date hardcoded format drives to "Error converting data type varchar to datetime" Jan 23, 2023
@kenjis
Copy link
Member

kenjis commented Jan 24, 2023

Thank you for reporting.

Can SQL Server accept YYYY-MM-DD H:i:s for the column?
I believe this is standard notation.

@kenjis kenjis changed the title Date hardcoded format drives to "Error converting data type varchar to datetime" LoginModel Date hardcoded format drives to "Error converting data type varchar to datetime" Jan 24, 2023
@mikeabbott10
Copy link
Author

mikeabbott10 commented Jan 24, 2023

Yes, it can but my company wants it to not be modified. It's standard notation for some locales, not for all

@mikeabbott10
Copy link
Author

mikeabbott10 commented Jan 24, 2023

The title of this post should be edited. It's not about LoginModel only. It's about every datetime value insertion in db. The solution is to change the hardcoded 'Y-m-d H:i:s' string with a simple datetimeFormat constant saved somewhere. Please tell me where these kind of constants should go so i can solve this and make a PR

@kenjis
Copy link
Member

kenjis commented Jan 24, 2023

We thought Y-m-d H:i:s is safe to databases regardless of locale.
So once we added Time::toDatabase() but removed it before the release.
codeigniter4/CodeIgniter4#6509
codeigniter4/CodeIgniter4#6461

Please tell me where these kind of constants should go so i can solve this and make a PR

I'm not sure, but

  1. add Time::toDatabase() and make it configurable with Config file for it.
  2. add in CodeIgniter\Shield\Config\Auth.

@mikeabbott10
Copy link
Author

mikeabbott10 commented Jan 24, 2023

I've just noticed that codeigniter 4 hardcodes the format too. They call "datetime" the "SQL datetime format" as you can see here .
I think it's a mistake because there are many datetime formats a sql server might expect. My server, for example, expects DMY and not YMD as they hardcoded there.
So maybe it's more complicated than it seemed.

Relative to codeigniter Shield, the solution would be to overwrite all the fields that BaseModel inserts automatically with that date format (i'm thinking about 'created_at' or 'updated_at' but maybe there are more). But I think it's not worth it at this point since we can move this discussion on CI4 and, after we fixed it on that side, we can make a simple constant adjustment here as we said before

@kenjis
Copy link
Member

kenjis commented Jan 25, 2023

Yes, the datetime (and date only) format for database is related to data from and to database,
and all the CI4 applications. Not only for Shield.

@kenjis kenjis changed the title LoginModel Date hardcoded format drives to "Error converting data type varchar to datetime" DateTime hardcoded format drives to "Error converting data type varchar to datetime" Jan 25, 2023
@kenjis kenjis changed the title DateTime hardcoded format drives to "Error converting data type varchar to datetime" DateTime hardcoded format Y-m-d H:i:s drives to "Error converting data type varchar to datetime" Jan 25, 2023
@jozefrebjak
Copy link
Contributor

jozefrebjak commented Jan 27, 2023

@mikeabbott10 Why do you need to store datetime in a different format? I'm from Europe as well and I'm using DDMMYY for users in WEB UI and I don't have any problems at all. I'm using a simple app_date helper function from Bonfire2 to translate datetime columns to a format I want and it's configurable.

I don't understand why somebody is changing the language of the database or Linux to the native one. I'm from Slovakia and I'm fine with the default settings of DB and CodeIgniter at all.

As @kenjis noted, YYYYY-MM-DD H:i:s is a standard. For me, it's a bad decision in your company to use something else.

@mikeabbott10 Don't take it the wrong way, just an opinion.

@mikeabbott10
Copy link
Author

YYYY-MM-DD H:i:s is a standard. For me, it's a bad decision in your company to use something else.

Not my decision and there's no turning back but as far as i know, since choosing a date format is legit a framework like this should also consider this possibility.

@datamweb
Copy link
Collaborator

datamweb commented Feb 1, 2023

  1. add Time::toDatabase() and make it configurable with Config file for it.

I think this issue should be resolved in the framework, it's not just for Shield and anyone else may have this problem in their own code.

it's a bad decision in your company to use something else.

I agree, but I don't think there should be a limit to any format. I think it doesn't matter why the user uses a different format, the important thing is the coverage of the framework and the ability to make orders, we should allow the user to have the ability to make orders.

@datamweb
Copy link
Collaborator

@mikeabbott10 Kenji made some changes to solve this problem, if you can check from the develop branch.

@kenjis kenjis reopened this Feb 24, 2024
@kenjis
Copy link
Member

kenjis commented Feb 24, 2024

To fix this issue, we need CI v4.5.0 (codeigniter4/CodeIgniter4#8538), and Shield develop branch.

@datamweb
Copy link
Collaborator

Oh, I thought the version released today was 4.5. Sorry.

@kenjis
Copy link
Member

kenjis commented Apr 14, 2024

@mikeabbott10
This bug should be resolved in CI 4.5.1 and Shield 1.0.3.

@kenjis kenjis closed this as completed Apr 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants