Seriously guys?
-
Richard MacCutchan wrote: There is actually a work-around, make sure dd comes first in the date. Good luck 'mercans. Big Grin | :-D I would make sure dd comes last. yyyy-mm-dd is my default format.
-
I tried to make a struct with two fields named mm and mmm respectively. The compiler accepted it without any warning. Confusing, isn't it? :-)
Religious freedom is the freedom to say that two plus two make five.
-
I tried to make a struct with two fields named mm and mmm respectively. The compiler accepted it without any warning. Confusing, isn't it? :-)
Religious freedom is the freedom to say that two plus two make five.
-
If you wish to format a date in Power Apps, there is a nice set of format letters to provide custom output. So using the Text function I can write
Text(myDate, "mmm dd yy") // May 09 24
Or for time I can write
Text(myTime, "hhmm") // 1644
Or I can combine them into
Text(myDateTime, "hhmm mmm dd yy") // 1644 16 09 24
Why would anyone think to use the same lower case letters for two very distinct fields? There is actually a work-around, make sure dd comes first in the date. Good luck 'mercans. :-D
Richard MacCutchan wrote:
Why would anyone think to use the same lower case letters for two very distinct fields?
History? Following has 'd' and 'D'. And 'c' and 'C'. Formatting Calendar Time (The GNU C Library)[^] Then there is "C Programming Language 2 edition" copyright 1988 which uses 'm' for minute and 'M' for month. And others.
-
If you wish to format a date in Power Apps, there is a nice set of format letters to provide custom output. So using the Text function I can write
Text(myDate, "mmm dd yy") // May 09 24
Or for time I can write
Text(myTime, "hhmm") // 1644
Or I can combine them into
Text(myDateTime, "hhmm mmm dd yy") // 1644 16 09 24
Why would anyone think to use the same lower case letters for two very distinct fields? There is actually a work-around, make sure dd comes first in the date. Good luck 'mercans. :-D
-
If you wish to format a date in Power Apps, there is a nice set of format letters to provide custom output. So using the Text function I can write
Text(myDate, "mmm dd yy") // May 09 24
Or for time I can write
Text(myTime, "hhmm") // 1644
Or I can combine them into
Text(myDateTime, "hhmm mmm dd yy") // 1644 16 09 24
Why would anyone think to use the same lower case letters for two very distinct fields? There is actually a work-around, make sure dd comes first in the date. Good luck 'mercans. :-D
-
I always use yyyy-MM-dd or dd MMM yyyy and always include timezones with times. Multiple hemispheres/countries/etc
-
What if they need the minutes, then the three letter month, then the minutes again, then the two digit numeric month? We won't ask why, but hypothetically speaking...
Doesn't PowerApps know whether it is formatting a time object or a date object? That would surprise me a lot. If I were to develop a formatting function, and was told "No no - you can't use that character to indicate a certain formatting - it has been used to format a very distinct field in a another value type", then I would scream out in protest. I cannot let the format strings for "my" type be limited by the format strings for all other types! That being said: Doing detail formatting of times and dates is blatant anti-internationalization, an explicit effort to make it difficult to adapt you solution to other markets, an invitation for customers outside your own locale to misunderstand or not understand the data you output. Don't do that! Use locale dependent formatting, and stop fiddling around with literal format strings!
Religious freedom is the freedom to say that two plus two make five.
-
Fine, but if you read my post you will see that "MM" or "MMM" are not valid format specifiers.
-
Forget about all format specifiers and use locale dependent formatting. Forcing your own locale formatting down the throat of customers in other locales is a bad thing to do.
Religious freedom is the freedom to say that two plus two make five.
-
Doesn't PowerApps know whether it is formatting a time object or a date object? That would surprise me a lot. If I were to develop a formatting function, and was told "No no - you can't use that character to indicate a certain formatting - it has been used to format a very distinct field in a another value type", then I would scream out in protest. I cannot let the format strings for "my" type be limited by the format strings for all other types! That being said: Doing detail formatting of times and dates is blatant anti-internationalization, an explicit effort to make it difficult to adapt you solution to other markets, an invitation for customers outside your own locale to misunderstand or not understand the data you output. Don't do that! Use locale dependent formatting, and stop fiddling around with literal format strings!
Religious freedom is the freedom to say that two plus two make five.
