I am using GetDateFormatEx (more specifically, ctypes.windll.kernel32.GetDateFormatEx using Python), which is documented at
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318088%28v=vs.85%29.aspx
And using today's date as the SYSTEMTIME input, and a NULL format string and 0 flags. however specifically for the ar-SA locale.
It is returning a value of "06/01/37", which is not what I expected. I expected to be in the ar-SA language (ie, what, in my English eyes, look like squibbles).
I also expected it would return an arabic short date string, specifically, for the gregorian calendar, however it seems to be using the Hijri calendar instead. How do I detect that a Hijri calendar is being used?
So, to re-iterate, what I want to know is:
How do I get the arabic date, something more like: تشرين الأول أكتوبر ١٩ ١٥
How do I detect the type of calendar that the user is expecting to be using?
Is it possible that you yourself has overridden the locale settings for date formatting on your testing PC? Maybe you need to use the LOCALE_NOUSEROVERRIDE flag.
UPDATE
I have tested this in C++
GetDateFormatEx(L"ar-SA", LOCALE_NOUSEROVERRIDE | DATE_AUTOLAYOUT | DATE_LONGDATE, nullptr, nullptr, buf, _countof(buf), nullptr);
The resulting date is
06/محرم/1437
UPDATE 2
This apparently depends on how Windows define the locale. I have tried different combination of the flags (DATE_AUTOLAYOUT | DATE_LONGDATE, DATE_AUTOLAYOUT | DATE_USE_ALT_CALENDAR | DATE_LONGDATE, DATE_AUTOLAYOUT | DATE_USE_ALT_CALENDAR). While for "ar-SA" this gives
06/محرم/1437
06/01/1437
06/01/37
for "ja-JP" (Japanese) it gives
2015年10月19日
平成 27年10月19日
平成 27/10/19
I suspect (not knowing full Windows NLS capabilities), you will have to use either specific formatting string or some other library, like ICU, to get more squigly dates.
UPDATE 3
It probably does not get any more squigly than with DATE_AUTOLAYOUT | DATE_USE_ALT_CALENDAR flags and L"dddd, dd MMMM, yyyy gg" format:
الإثنين, 06 محرم, 1437 بعد الهجرة
UPDATE 4
Further search reveals this:
Note: If you got the Gregorian date with Arabic names, then you probably forgot to set the calendar type to the Hijri calendar.
So it seems your Windows would have to have the Hijri calendar selected in your locale for the numbers to get formatted with the traditional numerals.
UPDATE 5
Finally, how do I detect that the Hijri calendar is being used in that case?
You can detect the calendar that is in use by calling GetLocaleInfoEx() with LOCALE_ICALENDARTYPE as its LCType parameter and comparing the returned number with constants defined in WinNls.h:
#define CAL_HIJRI 6 // Hijri (Arabic Lunar) calendar
#define CAL_UMALQURA 23 // UmAlQura Hijri (Arabic Lunar) calendar
Related
There is a finite list of date formats that users want to use to enter a date in a form. These formats include single digits for month and day and double digits for year. The field is represented by a dateText control.
How would one get to allow a dateText control to accept multiple date formats ? I see only 3 listed (https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GZCP_forms_dateText), do those include using single digits for month and day ?
I tried to set the value of format = "#(myPageProperty.myValue)# " but I got a compilation error in Studio so that went nowhere. Has anyone ever been able to set the format value depending on the user input value?
I am guessing that the control input value must be converted to the YYYY-MM-DD before validation. I am open to calling a javascript function to do that but where would be the best place to put it?
for details see Class %ZEN.Component.dateText
setting format:
Property format As %ZEN.Datatype.string(MAXLEN = 3, **VALUELIST = ",MDY,DMY,YMD",** ZENEXPRESSION = 1)
you have exactly 3 formats or ""
Your guess on values is correct and documented:
/// The value of this control is always in the canonical form: YYYY-MM-DD
As this is one of the oldest components of ZEN your only chance to achieve
your way of operation is to create your own version inheriting from
Class %ZEN.Component.dateText and overloading the parts you want to change
In my inputFields of zapier, there's one field where the user can enter the date but I want the zapier to work only if I write the date in "2020-09-18T15:30" otherwise it should show a message that the data entered does not match the format specified. I tried this but it's not working.
const activityEditableFields = async (z, bundle) => {
if (bundle.inputData.dueDate) {
(/\d{4}-\d{2}-\d{2}T\d{2}:\d{2}Z/.test(`${bundle.inputData.dueDate}`))
}
here duedate in the field and I am giving the format that if there is data in it then it should match the specified format but there's no difference in the zap. If you can help me as soon as possible. Do reply.
This shouldn't be necessary. Per the docs:
DateTime fields let users enter dates and times, using their human readable values, machine readable datetimes, or standard English words for time like tomorrow. Zapier interperpates the date input from users and outputs a standard ISO 8601 datetime to your API.
If you declare the field as a datetime, then bundle.inputData.dueDate will always be a proper ISO 8601 datetime.
The easiest way I could find to workaround this issue was to use with JS code only the first 10 characters of the ISO8601 Zapier date.
bundle.inputData.dueDate.substr(0,10)
or to use moment to parse date (This library is supported by Zapier):
const moment = z.require('moment');
....
moment(bundle.inputData.dueDate).format("YYYY-MM-DD HH:MM:SS UTC")
The only drawback is that you need to use the code editor
I'm trying to get the long time format in Windows (like "hh:mm:ss tt"). I can get the short time format like this:
GetLocaleInfoEx(NULL, LOCALE_STIMEFORMAT, format, 100);
I can't seem to find a constant for LOCALE_LTIMEFORMAT or anything like that. I can get the short time, short date and long date, but how can I query the current user's long time format?
As far as I can tell, windows defines the 'long' time format by LOCALE_STIMEFORMAT (set to something like "hh:mm:ss"), and the short time as LOCALE_SSHORTTIME (which, according to MSDN, is valid for Windows 7 and later).
Does that correspond to your findings, i.e. does it match the user preference in the Region and Language Control Panel item?
For the t specifier, if it is not included into the locale format, then either you are left with always using a custom format (like gbjbaanb said), or perhaps examining the format string for the presence of t or tt, and if absent adding it yourself (though, this might lead to odd results for cultures expecting the tt before the general time, for instance). This should not be necessary though, as the time format used by the locale is responsible for yielding time-strings that make sense (distinguishing between AM and PM, for instance).
What you are looking for is already included in LOCALE_STIMEFORMAT. Sample code:
wchar_t format[80]; // 80 is always enough
int ret = GetLocaleInfoEx(
LOCALE_NAME_USER_DEFAULT,
LOCALE_STIMEFORMAT,
format,
sizeof(format) / sizeof(*format));
if (ret == 0) die(GetLastError());
std::wcout << format << std::endl;
Output on my machine (I live in the USA):
h:mm:ss tt
The "tt" part will be absent for any culture or locale customization that does not display the AM/PM designator.
The LOCALE_STIMEFORMAT is the long time format. To get the short time format you can use LOCALE_SSHORTTIME starting with Windows 7 or cut off the seconds.
To confirm this simply change the long time format in your Control Panel / Region and Language settings.
Try using it with the LOCALE_S1159 and LOCALE_2359 constants which return the text for the AM/PM designators.
I think the issue is that time format is a time format, down to the second. You have to format it yourself if you want AM/PM just like you do with daylight savings time or timezone indicators.
CodeIgniter stores timezones for its date class in
system/language/english/date_lang.php
I would like to change the strings in this file so that
$lang['UM12'] = '(UTC -12:00) Baker/Howland Island';
$lang['UM11'] = '(UTC -11:00) Samoa Time Zone, Niue';
would instead be
$lang['-12:00'] = '(UTC -12:00) Baker/Howland Island';
$lang['-11:00'] = '(UTC -11:00) Samoa Time Zone, Niue';
Is this possible at all?
Any change I make to the UM__ portion of one line makes it show as a blank on the dropdown. The remaining (unchanged) lines appear OK.
I have also tried to clone this file to application/language/english/ with similar bad results.
Any insights on this?
It looks like this would require hacks to the date_helper.php file which I am not willing to do.
Instead, the date class in CI has the timezones() function which allows you to convert from, for example, UM5 to -5. In that case one can wrap this function around the U__ value coming from the view/dropdown -- and then save it to DB as -5 or some other INT.
Since I want to show the user their selected timezone on that same dropdown, I am forced to have DB fields for the U__ and INT timezone formats. As far as I know, there is no CI function to convert from -5 to UM5.
So, for the user, I pull the U__ format into the view to autopopulate the dropdown.
For timezone conversions and such, I use the INT format.
Is there a way to get a 2 character day-name of the week such as MO/TU/WE/TH/FR/SA/SU?
Currently I only know of using FormatDateTime():
"ddd" returns "Fri"
"dddd" returns "Friday"
The main reason is that I want to obtain localized version of the 1 or 2 character day names:
Say FRIDAY in "ddd" would return:
French Windows = "Vendredi", the 2 char would be "VE", note it's the 1st and 2nd char.
Chinese Windows = "星期五", the char would be "五", note it's the 3rd char.
Japanese Windows = "金曜日", the char would be "金", note it's the 1st char.
Edit1:
Currently using Delphi, but i think applies to other languages too.
Edit2:
Simply put, I'm looking to obtain the shorter version of "ShortDayName" through the use of some functions or constants, so that I don't have to build a table of constants containing the 7 day "Shorter" day names for every possible windows language.
I wonder if such functions really exist.
Maybe the calendar 1 or 2 char day names in Outlook are hard-coded themselves, right?
You can get the local names for the days of the week with ShortDayNames and LongDayNames, and you can use DayOfWeek to get the numeric value for the day.
ShortDayNames[Index]; //Returns Fri
or
LongDayNames[Index]; //Returns Friday
The only way I know to shorten them to two chars would be to trim the resulting string
LeftStr(LongDayNames[Index],2);//Returns Fr
So today's Day would be
LeftStr(LongDayNames[DayOfWeek(date)],2); //Returns Fr
Click Here
Depicts the standards in custom date formatting.
You may also use the 'ddd' standard and trim it.
Delphi's routines does nothing special - they just ask OS.
Here is how to to it: Retrieving Time and Date Information. I looked through MSDNs docs and found this.
Note, that there is no really such thing as "2 character day-name" or "3 character day-name" here. There are: native ("long" in Delphi), abbreviated ("short" in Delphi) or short (Vista and above, not present in Delphi) formats.
For example, abbreviated name of the day of the week for Monday: Mon (3 chars, en-US), Пн (2 chars, ru-RU).
So, you probably look for LOCALE_SSHORTESTDAYNAMEX format (which is called "short" by MSDN and doesn't appear in Delphi), but it is availavle only on Vista and above.
For example, the following code:
const
LOCALE_SSHORTESTDAYNAME1 = $60;
procedure TForm1.Button1Click(Sender: TObject);
begin
SetThreadLocale($409);
ShowMessage(
GetLocaleStr(GetThreadLocale, LOCALE_SSHORTESTDAYNAME1, '') + #13#10 +
GetLocaleStr(GetThreadLocale, LOCALE_SABBREVDAYNAME1, '')
);
end;
will show you:
Mo
Mon
But doing this for Russian will output:
Пн
Пн
Hope my edits make answer more clear ;)