Leaderboard

installing Japanese too because Greek was too easy 🤣 I think we call those two functions and recreate the user's string from that but as I am right now ( the headache ), I don't know if it makes sense to go that way 🤷‍♂️ Edit: Done | 0 - date and/or time. | 1 - long date, regional settings. | 2 - short date, regional settings. | 3 - time, regional settings. | 4 - time 24-hour (hh:mm). | 5 - time 24-hour (hh:mm:ss). | 6 - time AM/PM (hh:mm tt). | 7 - time AM/PM (hh:mm:ss tt). | 2025/09/28 11:40:29 | 2025年9月28日 | 2025/09/28 | 11:40:29 | 11:40 | 11:40:29 | 11:40 午前 | 11:40:29 午前 | 2025/12/31 11:59:59 | 2025年12月31日 | 2025/12/31 | 11:59:59 | 11:59 | 11:59:59 | 11:59 午前 | 11:59:59 午前 | 2025/12/31 23:59:59 | 2025年12月31日 | 2025/12/31 | 23:59:59 | 23:59 | 23:59:59 | 11:59 午後 | 11:59:59 午後 | 2025/12/31 11:59:59 | 2025年12月31日 | 2025/12/31 | 11:59:59 | 11:59 | 11:59:59 | 11:59 午前 | 11:59:59 午前 | 2025/12/31 23:59:59 | 2025年12月31日 | 2025/12/31 | 23:59:59 | 23:59 | 23:59:59 | 11:59 午後 | 11:59:59 午後 So I guess Japanese has a simple format, I guess. I installed it because MSDN say: "g, gg Period/era string formatted as specified by the CAL_SERASTRING value. The "g" and "gg" format pictures in a date string are ignored if there is no associated era or period string." and Japanese should have these ? "Year represented by a full four or five digits, depending on the calendar used. Thai Buddhist and Korean calendars have five-digit years. The "yyyy" pattern shows five digits for these two calendars, and four digits for all other supported calendars. Calendars that have single-digit or two-digit years, such as for the Japanese Emperor era, are represented differently. A single-digit year is represented with a leading zero, for example, "03". A two-digit year is represented with two digits, for example, "13". No additional leading zeros are displayed." We could use one user from every country to make sure. ..or we'll add it in a next version. I don't know any of these languages and cultures and I'll guess wrong. So I'll stop installing more VMs. "Hindsight is 20/20"

The laughter was from surprise that you mentioned "Nominative Case vs. Genitive Case" my other question is (because you are referring to a single string for the date and time) now we get the date from _WinAPI_GetDateFormat($iLcid, $tSystem, 0, $sTempDate) and the time from the time from _WinAPI_GetTimeFormat($iLcid, $tSystem, 0, $sTempTime) so we have two strings $sTempDate, and $sTempTime If we had them in a single string $sTempDateTime, is there a function to give us the date and time? Or would we have to find where to split it , to call _WinAPI_GetDateFormat , and _WinAPI_GetTimeFormat ? Edit: For the headache, I would tell you to take paracetamol, but I heard that it causes autism.

...not really. Say "dddd, d' de 'MMMM' de 'yyyy' a las 'hh:mm tt|am|pm" vs "dddd, d' de 'MMMM' de 'yyyy' a las 'HH:mm tt|am|pm" One is 12 hour and the other 24 hour as per M$: "In the format types, the letters "m", "s", and "t" must be lowercase, and the letter "h" must be lowercase to denote the 12-hour clock or uppercase ("H") to denote the 24-hour clock." So if we follow M$ notation, it can all be resolved with just the custom string, and send the users to read MSDN's date and time rules. $vType would be a number 0 to 7 and if a string ( "dddd, d' de 'MMMM' de 'yyyy' a las 'HH:mm tt|am|pm" ), then we chop that up and rebuild it from the values from the _WinAPI_Get*Format() functions. It makes sense in my head. But I'd have to code it to know that it is possible. Also, I'd have to see for myself the "Σεπτεμβρίου vs. Σεπτέμβριος". See if the OS returns the proper string for "Nominative Case vs. Genitive Case" ( of which am clueless ).