I need to write some date functions in Powershell for a current project, and a couple of those require the name of a day as param. Since I am writing this for an English speaking site, I will allow as valid inputs:
Mon, Tue, Wed, Thu, Fri, Sat, Sun
Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday
Mo, Tu, We, Th, Fr, Sa, Su
I want to put some of these into my toolkit, so I would like to make the script work in any language. I know how to use Import-LocalizedData for all my help texts and prompts, those are pretty easy.
Is there a way to have localized enums? Or is the better way to create enums in the most common languages and switch them based on the OS's current locale at runtime?
Related
Can't find a pattern for this date. Could anyone help me?
I know it's ISO 8601 standart.But everything I have found was without : between 03 and 00.
2018-01-18T08:40:00+03:00
How do I can parse this to Thu Jan 18 00:00:00 GMT+03:00 2018 to this 2018-01-18T08:40:00+03:00?
It looks like this W3C Datetime format is typically used for < lastmod > timestamps in XML.
related & more detailed answer here
I need to change the mailchimp locale *|DATE:M y|*. This gives Apr 2013 and I want Abr 2013 (Portuguese format). Is there any way to do this?
Thanks!
Have you tried wrapping the date with a translate merge tag?
*|TRANSLATE:PT|* *|DATE:M y|*
http://blog.mailchimp.com/automatically-translate-your-emails-to-over-30-languages/
The list of language codes can be found here:
http://kb.mailchimp.com/article/is-it-possible-to-translate-content-in-multiple-languages
But the Portugese options are:
Portuguese (Brazil) = pt
Portuguese (Portugal) = pt_PT
There you go
setlocale(LC_ALL, 'pt_PT');
echo strftime("%b %d %Y");
this will output
Abr 18 2013
To format dates in other languages, you need to use the setlocale() and strftime() functions
When trying to read a CSV yesterday, I noticed that PowerShell seems to always assume US date format when using [datetime]"date".
My regional settings are all correct, and [DateTime]::Parse("date") uses the UK date format (dd/mm/yyyy).
Is this a bug, or a deliberate decision? If a deliberate decision, is this documented anywhere?
PS D:\> [DateTime]"12/10/2012"
10 December 2012 00:00:00
PS D:\> [DateTime]::Parse("12/10/2012")
12 October 2012 00:00:00
(Note: on a US machine, I expect these objects will be the same, but not so here on my machines in the UK).
Note: I don't want to change the format (it's a file from an external source), I don't want to format dates in output, I know I can use [DateTime]::Parse(). The question is the bit that ends with a ? :-)
It is a deliberate decision. When casting a string to a DateTime you can use either the braindead US format or ISO 8601 – [datetime]'2012-10-12' works just fine and is much nicer to read.
The reason that this is limited and restricted is that scripts should not have a dependency on the current culture, at least for literals and quasi-literals (like casted strings). This is a major problem in writing robust batch files and you certainly don't want the same problems in PowerShell.
Lee Holmes has an explanation, which could be considered semi-official, as he is/was on the PowerShell team at MS:
To prevent subtle internationalization issues from popping into your scripts, PowerShell treats [DateTime] '11/26/2007' (a date constant) like a language feature – just as it does [Double] 10.5 (a numeric constant.) Not all cultures use the decimal point as the fractions separator, but programming languages standardize on it. Not all cultures use the en-US DateTime format, resulting in millions of internationalization bugs when people don’t consider the impact of having their software run in those cultures.
What Lee forgets to mention is what I wrote before, that the much more sensible ISO 8601 format works as well.
No documentation of this exists in either the PowerShell documentation or the Language Specification (v2), sadly. However, there is very little evidence that points to this being a bug.
You can force the culture for a single command if needed:
PS C:\> [System.Threading.Thread]::CurrentThread.CurrentUICulture = "en-US" ; [System.Threading.Thread]::CurrentThread.CurrentCulture = "en-US"; [DateTime]::Parse("12/10/2012")
Monday, December 10, 2012 12:00:00 AM
PS C:\> [System.Threading.Thread]::CurrentThread.CurrentUICulture = "en-GB" ; [System.Threading.Thread]::CurrentThread.CurrentCulture = "en-GB"; [DateTime]::Parse("12/10/2012")
12 October 2012 00:00:00
I would like to display a date like...
=Now.ToLongDateString()
BUT without the weekday. So the expression would produce June 21 2011. Not Tuesday, June 21 2011. Is this possible? I don't want the format MM/DD/YY. I would rather have June 21 2011.
I have found an expression that works. This is here for others to use.
=FORMAT(Now,"MMMM dd, yyyy")
I don't like answering my own questions because most here think its a reputation point thing (which its not) SO, If anyone else provides an answer that is more helpful or is "neater", I will toggle off my checkmark and mark yours. Otherwise, I'll leave this up so others can use the answer as per Meta.
I'm successfully setting a date-picker with an initial date from a plist, but I see some unwanted blue values in the month, day, and year components, presumably corresponding to current date. So if today is April 18, 2010 and initial date being set is March 19, 2008, it looks like this (bold represents the blue):
January 17 2006
February 18 2007
------------------------------
March 19 2008
------------------------------
April 20 2009
May 21 2010
First question is: How do I get rid of the blue?
And second question: Ideally, how do I get it to look like this?
January 17 2006
February 18 2007
------------------------------
March 19 2008
------------------------------
April 20 2009
May 21 2010
Third question, totally unrelated and not as important: How could I have gotten the above to show in blue rather than bold? I see blue in code snippets all the time.
Matt
Sadly, I do not believe it's possible to suppress the coloring of the current date components in blue. You could always file a feature request for this functionality.
As a last resort, you could implement your own (or Google for "generic date picker" - someone has already done this).
I think the code sample formatter automagically makes things blue that it thinks are keywords, like:
UIDatePicker* myPicker;
I didn't tell it to make that blue, it just is.