I am trying to send a DateTime from one process to another. My first thought was to send the DateTime as a string and parse the string back to DateTime onces received. Unfortunately on some machines I get a FormatException even though the string looks good e.g. "31.10.2019 12:00:00" (no hidden characters).
The code looks like this, I will omit the communication since the string is correctly transferred.
var datetimeAsString = SomeDateTime.ToString(); // "31.10.2019 12:00:00"
Pipe.Send(StringToBytes(datetimeAsString));
// Data gets send
var datetimeAsString = BytesToString(receivedBytes); // "31.10.2019 12:00:00"
var datetime = DateTime.Parse(datetimeAsString);
Please note that it works on some machines.
TL;DR
When trying to send DateTime between different systems, do NOT convert it to a string using ToString() without parameter use DateTime.ToBinary and DateTime.FromBinary instead OR if you want a string specify a culture e.g.
var datetimeAsString = thisDate.ToString(new CultureInfo("en-us"));
DateTime.Parse(datetimeAsString, new CultureInfo("en-us"));
PS: I think this not only applies to situations where you want to exchange data but also to other situations and therefore should be seen as a general advice.
--
The problem was that the software that sent the DateTime converted the DateTime.ToString() to a German format, even though the software was in English. The receiving software was sometimes in German and sometime in English. The software with the German language was able to use DateTime.Parse on the German string, the other systems weren't.
The solution was to not convert the DateTime to a string but to a long using the DateTime.ToBinary method. I think is would also been possible to solve it with CultureInfo.InvariantCulture, but we thought long was much cleaner.
Related
I have a use case that I'm not sure how to solve in a nice way.
I'm currently developing a .Net Core WebApi that is receiving data from various current systems, from a cross the whole world. Which I then process and lastly I commit it to SAP through oData endpoint.
The problem I'm having is on of parameters I'm receiving in the body payload, is a DateTime. Previous I have not have any issues. But not long ago I started getting data from a other system which deliverers it in a slightly differently way.
Previously this was the format I got: 2020-09-16T16:30:00 not problem with it. But the new system looks like this: 2020-09-16T16:00:00 -05:00 Could also end in +08:00.
The problem I'm facing is that SAP needs to get in local time. But in the my code it converts this: 2020-09-16T16:00:00 -05:00 to 2020-09-16T23:00:00 when I see the incoming payload in the controller.
I have searched quite a bit to find a solution. But 99% only suggest using UTC time, which is not a option for me.
Another option is to use DateTimeOffset, which I have tried but can't the time conversion to use localTime.
My question is. Are it not possible to custom convert to strip the timezone before it hits the controller?
Generarally when you're working with datetime data that includes offsets for time zone the DateTimeOffset type is a good place to start. The sample string 2020-09-16T16:00:00 -05:00 can be passed to DateTimeOffset.Parse() to get a correct DTO value with timezone information attached. From there you can get the local time, UTC time or a DateTime value with the timezone stripped.
string source = "2020-09-16T16:00:00 -05:00";
string fmt = #"yyyy-MM-dd\THH:mm:ss zzz"
// Same as input
Console.WriteLine(DateTimeOffset.Parse(source).ToString(fmt));
// Adjusted to your local timezone
Console.WriteLine(DateTimeOffset.Parse(source).ToLocalTime().ToString(fmt));
// DateTime portion of the source, timezone offset ignored
Console.WriteLine(DateTimeOffset.Parse(source).DateTime.ToString());
Getting the UTC time is simple too via the UtcDateTime property.
It sounds like what you want is the last one - just the date and time from the inputt string with the timezone offset stripped. If you just want the corresponding local time then DateTime.Parse should give that to you directly.
The JsonSerializer class doesn't support this format for DateTimeOffset so you might have some trouble getting it converted before hitting your controller. In that case you'd need to accept a string and do the conversion by hand in your code. You also might need to investigate the TryParseExact method.
Use DateTime.Parse() , for example
string timeInString1 = "2020-09-16T16:00:00 -05:00";
DateTime moment1 = DateTime.Parse(timeInString1);
string timeInString2 = "2020-09-16T16:00:00 +08:00";
DateTime moment2 = DateTime.Parse(timeInString2);
string timeInString3 = "2020-09-16T16:30:00";
DateTime moment3 = DateTime.Parse(timeInString3);
but momen1, momen2, or moment3 is non-timezone awareness value.
I want datetime.now to return the datetime object in UK format. It does so on my local computer but when I upload the code to the server it does it in US format
DateTime doesn't have any format associated with it. Formatting is just for presentation. You can do:
string formattedDate = DateTime.Now.ToString(CultureInfo.CreateSpecificCulture("en-GB"));
Or supply a specific/custom format like:
string formattedDate = DateTime.Now.ToString("dd/MM/yyyy HH:mm:ss",
CultureInfo.InvariantCulture);
I want datetime.now to return the datetime object in UK format.
There's no such concept, any more than an int is a value "in hex" or "in decimal". A DateTime is just a DateTime - you can specify the format when you convert it to a string. It's really important to understand the difference between an inherent value, and what it looks like after it's converted to text - very few types are aware of a custom, modifiable format to use when converting themselves - it's either provided externally (as for DateTime, numbers etc) or simply fixed.
Before you convert start hard-coding a UK format though, I would strongly advise you to consider exactly what you're doing:
Ideally, avoid the conversion in the first place. A lot of the time, string conversions are unnecessary and can be problematic.
Is the text going to be consumed by another machine? Use an ISO-8601 standard format.
Is the text going to be consumed by a person? Use their culture rather than some arbitrary one you decide on.
... Or display it in a dedicated control...
You can use the overload of the ToString method: ToString("dd/MM/yyyy"), or: ToString("yy/MMM/dd"), etc. etc.
Read more about it here: https://msdn.microsoft.com/en-us/library/zdtaw1bw%28v=vs.110%29.aspx
Also sounds to me that you might want to configure your (UI-)Culture in the web.config? Then it will always be in the same format regardless of the culture of your US/Japanese/european server culture..
More about that here: https://msdn.microsoft.com/en-us/library/bz9tc508%28v=vs.140%29.aspx
LogDate = DateTime.UtcNow.AddHours(1);
I'm using the Parse method to convert a string to a DateTime object:
requestRecord.TerminationDate = DateTime.Parse(reader.ReadString("Termination_Date"));
This code works on one machine but throws an exception on the other. I think the issue may perhaps be to do with the local culture. Looking at the taskbars on the two machines the one that throws the exception has the date as 01/12/2014 whereas the other shows 12/01/2014.
Is there some way that I can rewrite the above code so that it works on both machines regardless of the local DateTime culture?
I guess the culture settings differ on both machines. Try to supply the format. That explains why the date format is interpreted differently on both machines:
requestRecord.TerminationDate = DateTime.ParseExact
( reader.ReadString("Termination_Date")
, "dd/MM/yyyy"
, CultureInfo.InvariantCulture
);
In this way, you are not depending on the machine and it's settings, but on the format you know.
Depending on what reader is, you might want to use reader.GetDateTime, which does all this for you already, for example SqlDataReader.GetDateTime.
I have a DateTime being created in the format dd/MM/yyyy HH:mm:ss. I am writing code that interacts with a third-party SOAP library that requires a DateTime variable, in the format yyyy-MM-dd HH:mm:ss.
How do I change the way the information is stored in the DateTime variable, for the purpose of the call to the third-party SOAP library, i.e. no system-wide changes to dates?
I have investigated CultureInfo, which is mildly confusing and possibly too permanent a solution; the only time I need the DateTime changing is for an instance of this single call.
As an explanation, the library has a function GetOrders(DateTime startDate, DateTime endDate, TradingRoleCodeType roleType, OrderStatusCodeType statusType). When attempting to perform the function with DateTimes as created, it generates an error "Sorry, the end date was missing, invalid, or before the start date. must be in YYYY-MM-DD or YYYY-MM-DD HH:MI:SS format, and after the start date.". Given the format that is passed in as dd/MM/yyyy HH:mm:ss, I'd think this may be the problem.
I have a DateTime being created in the format dd/MM/yyyy HH:ii:ss
No, you do not. You have a DateTime. It has no format. It is a number - which is well documented, you know, in the documentation. The string form is never used in a stored DateTime, only when generating the string for presentation.
How do I change the way the information is stored in the DateTime
variable, for the purpose of the call to the third-party SOAP library,
i.e. no system-wide changes to dates?
You do not. I would suggest you talk to your SOAP library - and it is not SOAP btw., IIRC the format you give as example is not valid in SOAP. Yes, bad news. Someone wants Pseudo-Soap.
http://www.w3schools.com/schema/schema_dtypes_date.asp
describes all valid date, time and datetime formats and yours is NOT there.
You can change the default format on a thread level back and forth, so one solution is to set it before calls into the soap library. Another one is to have someone fix the SOAP layer to accept standard formats.
You can create a dummy date :
public class SomeClass
{
[XmlIgnore]
public DateTime SomeDate { get; set; }
[XmlElement("SomeDate")]
public string SomeDateString
{
get { return this.SomeDate.ToString("yyyy-MM-dd HH:mm:ss"); }
set { this.SomeDate = DateTime.Parse(value); }
}
}
Source : Force XmlSerializer to serialize DateTime as 'YYYY-MM-DD hh:mm:ss' --kbrimington
As it turns out, the problem - as some have pointed out - is not to do with the variable being a DateTime, nor its "format" which is not a "format", but is certainly the representation of the information in a method to be understood.
The basic issue with the information was a DateTime comparison between standard time and UTC time. The third-party library examined the DateTime as a UTC DateTime, which when at the right time of year to be caught with a difference in times can cause a problem comparing a DateTime; despite being presented as after the reference time to the user, the time is actually before the reference time when being calculated, meaning the comparison fails.
The main takeaway for this question is to interrogate the information being passed to functions, if you don't have access to third-party library code nor access to documentation with sufficient detail, and errors are occurring when interacting with said third-party code.
Particularly, test various use cases to determine what variable values cause a failure and which cause successful execution of code; identify a pattern, and then test specific use cases that confirm the pattern. From there, determine the actual error that is occurring and code to fix the issue.
In the case of DateTimes, where the code understands DateTimeKinds such as C#, remember to test the different DateTimeKinds to establish whether they can be a part of the problem; its not happened to me often, but it has happened (as evidenced by this question).
Finally, error codes don't help much, and can lead to poor questions and poor advice; trial and error appears to be the best in cases similar to this.
You don't need to change how it's stored, as already mentioned above.
You need to format is as a string according to ISO8601, which is what your SOAP service expects datetime parameter to be.
Check How to parse and generate DateTime objects in ISO 8601 format
and
Given a DateTime object, how do I get an ISO 8601 date in string format?
My website is hosted on multiple servers at different locations
Everywhere the Culture of the data format is different- we use mm/dd/yyyy format every where but incase some server has the culture set to dd/mm/yyyy then our website generates Datetime exception.
You should be specifying what culture you want to use whenever you convert a string to a date.
The culture you should be using depends on what culture the dates are formatted as. For example, if all dates you are parsing are formatted as Slovak:
String s = "24. 10. 2011";
Then you need to parse the string as though it were in Slovak (Slovakia) (sk-SK) culture:
//Bad:
d = DateTime.Parse(s);
//Good:
d = DateTime.Parse(s, CultureInfo.CreateSpecificCulture("sk-SK")); //Slovak (Slovakia)
If your dates are all in Tajik (Tajikistan Cyrillic), then you need to parse it as tg-Cryl-Tj:
String s = "24.10.11"
DateTime d = DateTime.Parse(s, CultureInfo.CreateSpecificCulture("tg-Cryl-Tj"));
Which leads to the question: what date format are you using? You should not be relying on the locale setting of the server, you should be deciding what format you want.
//Bad
String s = d.ToString();
//Good
String s = d.ToString(CultureInfo.CreateSpecificCulture("si-LK")); //Sinhala (Sri Lanka)
//s = "2011-10-24 12:00:00 පෙ.ව."
i suspect that you prefer to do everything in English. But then you have to decide which variant of English:
en-AU (English Austrailia): 24/10/2011
en-IA (English India): 24-10-2011
en-ZA (English South Africa): 2011/10/24
en-US (English United States): 10/24/2011
i suspect you prefer English (India) (en-IA).
But if you really can't decide what culture to use when converting dates to strings and vice-versa, and the dates are never meant to be shown to a user, then you can use the Invariant Culture:
String s = "10/24/2011" //invariant culture formatted date
d = DateTime.Parse(s, CultureInfo.InvariantCulture); //parse invariant culture date
s = d.ToString(CultureInfo.InvariantCulture); //convert to invariant culture string
Never, ever, store dates internally as strings. Not in the database, not in your app.
If you need to move date values between servers, go binary. Or if you really really have to use strings, use ToString(CultureInfo.InvariantCulture) - or simply serialize the Ticks property.
Also, never pass dates as strings to the database using SQL commands that you build using code. Use SqlParameter for that, or even better, rely on some O/R Mapper, such as Entity Framework or Linq to SQL.
If deployed to a server that's not under your control it's vitally important to make sure your code doesn't have hard-coded dependencies on the culture.
You'll most likely want to search your code for DateTime.Parse or similar. We have a set of extension methods on DateTime that we use instead to force the correct culture.
Never rely on the server's default locale. For your case, this means:
Use prepared statements where you pass the date as (unformatted) date object and not as (formatted) string object. You should never use strings to represent dates in your application anyway, as you cannot perform date-specific functions on them (like adding 1 month, getting the last day of the current week, etc.)
Use SQL functions like to_date and to_char everywhere (exact names depend on your DBMS), if you really need to use string objects in your application