date-format

Is the Joda-Time DateTimeFormatter class thread safe ? Once I get an instance from DateTimeFormat.forPattern , can its various parse methods be called by multiple threads? DateTimeFormatter's Javadocs makes no mention of thread safety. Erre Efe Yes, it is : DateTimeFormat is thread-safe and immutable, and the formatters it returns are as well. and so is the Java 8 version Implementation Requirements: This class is immutable and thread-safe. A quick look at the code shows there isn't any mutable shared state in DateTimeFormatter , which would make it thread safe. Found this question on top of

Is there an equivalent to php date() style formatting in Java? I mean, in php I can backslash-escape characters to have them treated literally. I.e. yyyy \y\e\a\r would become 2010 year . I did not find anything similar in Java, all examples deal only with built-in date formats. In particular, I deal with JCalendar date pickers and their dateFormatString property. I need it because in my locale it is required to write all sorts of additional stuff in date format, like d. (for day) after days part, m. (for years) after years part and so on. At the worst case I could use string replace or regexp

I've been searching all over and just can't find a explanation or reason why this is happening but the parse(String) method of DateFormat just isn't parsing my String correctly. I'm trying to parse a String into the date format that is used for HTTP headers and got as far as getting the String on its own such as: Thu, 11 Nov 2010 18:34:22 GMT Which is in the format: E, d MMM yyyy HH:mm:ss z But when I use df.parse(dateStr); this is what I get out of it: Thu Nov 11 18:34:22 GMT 2010 Which is nothing like what I wanted, why is the year now after the GMT? Why is there no comma anymore? And why is

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

One of our customers wants to be able to enter a date with only 2 digits for the year component. The date will be in the past, so we want it to work for the previous century if the 2 digit year is after the current year, but work for the current century if the 2 digit year is equal to or less than the current year. as of today 10/30/2008 01/01/01 = 01/01/2001 01/01/09 = 01/01/1909 This is a strange requirement, and I solved the problem, I just don't like my solution. It feels like there is a better way to do this. Thanks for the help. public static String stupidDate(String dateString) { String

This question already has an answer here: why does DateTime.ToString(“dd/MM/yyyy”) give me dd-MM-yyyy? 5 answers When i write a date in C# by using DateTime.Now.ToString("yyyy/MM/dd") then it returns 2010-09-10 , but I need 2010/09/10 . How do I make it output slashes? Lasse Vågsæther Karlsen Specify a culture. Your current culture uses - for the separators, and that's what ToString defaults to (your current culture), unless you override it. You can try this: DateTime.Now.ToString("yyyy/MM/dd", CultureInfo.InvariantCulture) but perhaps it would be better if you specified a different culture,