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

replace iconv with mb_convert_encoding #113

Merged
merged 2 commits into from
Feb 2, 2024

Conversation

connorhu
Copy link
Collaborator

The require-dev does not include the ext-iconv requirement, but tests use it. Since there is only one place with iconv call, I replaced it with mb_convert_encoding instead. mb-string require is there anyway.

@thirsch
Copy link
Collaborator

thirsch commented Jan 24, 2024

There are two more occurrences of iconv:

At least one argument is a variable, there it might be a BC as seen in here (ISO8859-15 vs. ISO-8859-15)?

@connorhu
Copy link
Collaborator Author

There are two more occurrences of iconv:

* https://github.com/FriendsOfSymfony1/doctrine1/blob/master/lib/Doctrine/Parser/Xml.php#L87

* https://github.com/FriendsOfSymfony1/doctrine1/blob/master/lib/Doctrine/Search/Analyzer/Utf8.php#L46

At least one argument is a variable, there it might be a BC as seen in here (ISO8859-15 vs. ISO-8859-15)?

I did not even check the source. However, we should also include ext-iconv.

@connorhu
Copy link
Collaborator Author

I was thinking. If the encoding is in a simple format then we can still do the ISO8859-15 => ISO-8859-15 conversion, but with iconv we can specify quite messed up variants (ascii//translit and others).

@thirsch
Copy link
Collaborator

thirsch commented Jan 24, 2024

I was thinking. If the encoding is in a simple format then we can still do the ISO8859-15 => ISO-8859-15 conversion, but with iconv we can specify quite messed up variants (ascii//translit and others).

My initial thoughts: Maybe it should just be added to the composer.json as it currently is a requirement and the code would crash if iconv is not installed. I'm not sure if it's worth the effort to change it.

@connorhu connorhu force-pushed the fix/iconv branch 5 times, most recently from c5275fd to c0350b4 Compare January 24, 2024 12:33
@connorhu
Copy link
Collaborator Author

I don't see why it failed, but the PR seems good.

@thirsch
Copy link
Collaborator

thirsch commented Jan 24, 2024

Looks like just bad timing...

The model under test uses the timestampable template and renames the created-field to event_date. Before time() is called later in the test, the model is created and saved. If the creation happens in the second before getting the current timestamp, the test condition will fail. It would be safer to test ($time => $now - 1).

Here is the test:

$elem = new Ticket_1325_TableName_NoAlias();
$elem->id = 1;
$elem->save();  // <-- here the current timestamp will be used (e. g. 1706130426)

$res = Doctrine_Query::create()
    ->from('Ticket_1325_TableName_NoAlias')
    ->fetchOne(array(), Doctrine_Core::HYDRATE_ARRAY);

$now = time();  // <-- the reference timestamp will be set here (e. g. 1706130427)
$time = strtotime($res['event_date']);
$this->assertTrue(($now + 5 >= $time) && ($time >= $now));

@thirsch
Copy link
Collaborator

thirsch commented Jan 25, 2024

[...] It would be safer to test ($time => $now - 1).

Or even better to move $now = time() up to determine the current timestamp before save() is called. :)

@thePanz thePanz merged commit 7327db8 into FriendsOfSymfony1:master Feb 2, 2024
5 checks passed
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 this pull request may close these issues.

3 participants