-
Notifications
You must be signed in to change notification settings - Fork 14
Footer in generated pdf should use dd.MM.yyyy HH:mm:ss #1334
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
Conversation
/publish |
PR release:
|
https://docs.altinn.studio//nb/altinn-studio/reference/ux/pdf/#forutsetninger Is it really better to fallback to UTC (in tt02/prod) than to error when someone doesn't read the documentation? |
/publish |
PR release:
|
Testing done: first test: Added loggin to the GetFooterContent method:
Output:
However, the footer reads:
successfully create the nb-NO culture, but it seems like something is overriding it or the format string "G" is not behaving as expected. Tests:
Results: TestGFormatWithNorwegianCulture_WithEmptyThreadCulture passed Conclusion: Local Environment: .NET culture formatting works correctly Next test: |
/publish |
PR release:
|
Explicit date format: The explicit format string "dd.MM.yyyy HH:mm:ss" bypasses the complex culture-dependent format resolution that the "G" specifier relies on. While the "G" format specifier is supposed to be culture-aware, it can fall back to system defaults when thread culture is not properly set, even when an explicit culture is provided to the method. The container logs confirmed the fix worked: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, but are seconds really necessary?
|
Please retry analysis of this Pull-Request directly on SonarQube Cloud |
Description
The explicit format string "dd.MM.yyyy HH:mm:ss" bypasses the complex culture-dependent format resolution that the "G" specifier relies on. While the "G" format specifier is supposed to be culture-aware, it can fall back to system defaults when thread culture is not properly set, even when an explicit culture is provided to the method and DOTNET_SYSTEM_GLOBALIZATION_INVARIANT: false
Another solution would be to update the docs on how to set up the dockerfile for pdf footer.
By adding default culture:
// Set .NET default culture
ENV DOTNET_DefaultCulture=nb-NO
ENV DOTNET_DefaultUICulture=nb-NO
This has not been tested though.
Related Issue(s)
Verification
Documentation