Bug 66248
Summary: | Add adaptation macro for Windows CRT strftime() '#' extension and use in formatLocaleDate() | ||
---|---|---|---|
Product: | WebKit | Reporter: | Daniel Bates <dbates> |
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | ap, mrobinson, paroga |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Daniel Bates
In function formatLocaleDate() in DataPrototype.cpp, we use the non-standard Windows CRT '#' extension for strftime() for the long date and time representation.
Currently, we don't use this non-standard extension when building for Symbian, and WinCE with Qt. The strftime() on QNX also doesn't support this extension and from what I can tell this extension is Microsoft-specific. Note, glibc does support the '#' extension for strftime() but it only switches the output between uppercase and lowercase characters, which is different from Microsoft's definition of '#'.
For completeness, Microsoft's definition of '#' is here, see the table that follows "As in the printf function, the # flag may prefix any formatting code...":
<http://msdn.microsoft.com/en-us/library/fe06s4ak(v=vs.80).aspx>
For Glibc, see section Glibc Notes of:
<http://linux.die.net/man/3/strftime>
We should consider defining a platform-adaptation macro for this non-standard extension, say HAVE_STRFTIME_WIN_HASH_FLAG, for platforms that support this extention (enabled for Windows only at the time of writing) instead of maintaining a list of OSes/configurations that don't support this extension.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Patrick R. Gansterer
<https://trac.webkit.org/changeset/97557> removed support for Symbian.
<https://trac.webkit.org/changeset/123293> added additional code for Windows.
AFAIK the Windows CRT strftime() isn't used anymore.
Since <https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/DatePrototype.cpp?rev=127505#L220> has no special case for QNX I think this issue can be closed.