So as an excercise in utility i've taken it upon myself to convert one of our poor old vb .net 1.1 apps to C# .net 4.0.
I used telerik code conversion for a starting point and ended up with ~150 errors (not too bad considering its over 20k of code and rarely can i get it to run without an error using the production source) many of which deal with time/date in vb versus c#.
my question is this how would you represent the following statement in VB
If oStruct.AH_DATE <> #1/1/1900# Then
in C#? The converter gave me
if (oStruct.AH_DATE != 1/1/1900 12:00:00 AM) {
which is of course not correct but I cannot seem to work out how to make it correct.
if (oStruct.AH_DATE != new DateTime(1900, 1, 1){
You may try this construct :
if ( DateTime.Compare(oStruct.AH_DATE, new DateTime(1900, 1, 1)) == 0 )
{
// your code here
}
Here is a reference how to compare DateTimes in .NET - DateTime.Compare Method
Note: Comparing two dates like integers may lead you to wrong results. Because, date-time structure in .NET has its specific properties. I would always try to be attentive when comparing two dates, and always choose DateTime.Compare to be on a safer side.
This should work:
if (oStruct.AH_DATE != DateTime.Parse("1/1/1900"))
Related
In C# on Windows Vista - 7 with dot net 4.0 or less
I am trying to compare the values of login time, current time, and the modified time of a file to see which is the greater and which is least. I have found ways to declare and cast these three values but not as the same type. I figured unix epoch made the most since and I seem to be stuck with converting the long format of
File.GetLastWriteTime("time.cs" )
Apparently overflows are a problem, who would have guessed, not my esp. Such a superior os & language. Anyway. Can someone please give me a full example of how to cast return and output the modified time of a file to int32 unix epoch. Or, can some one show me, in full example how to compare the above three values without trolling a log file or the use of jQuery or defining functions or languages beyond the scope of what I have requested. Speed is key and the parameters are required not optional.
The csharp crowd doesn't have the answer? there is a surprise. Well this is about as exact as there being 365 days in a year but for my purpose it will work. Because two forms of builtin not traversal date time isn't enough. For the pleasure of all that is prime and dec ten. A solution:
DateTime dt = File.GetLastWriteTime("time.cs");
var sec = ( ( dt.Year - 1970 )*31536000) + (dt.Month*2592000) + (dt.Day*86400) + (dt.Hour*3600) + (dt.Minute*60) + (dt.Second * 1) - 2592000 - 86400;
I guess for windows this is actually considered efficient. Can anyone tell my why DateTime isn't just considered a string? is base24 replacing base 16 or some thing? Did we add a register to our processor just for msns inefficiencies. Im going with the ladder. Front end convenience is no excuse for back end ugliness. Ill be posting a pure assembly answer next on how to convert gregorian to epoch via means of base 2 and 127 bit addressing... crazy.
I have the query
var result = (from myView in db.loginSessions
where myView.machine.ToUpper().Equals(machine.ToUpper())
&& myView.start >= myStart
&& myView.end <= myEnd
orderby myView.start
select new loginSessionList {
Id = myView.id,
Machine = myView.machine.ToUpper(),
Start = myView.start.ToString("u"),
End = myView.end.ToString("u"),
User = myView.username
}).ToList();
I get ArgumentOutOfRange exceptions on the datetime conversions. I have tried different ToString conversion strings. I have tried the other To... date->string conversions offered by Intellisence. I have tried Convert.string(myView.start). Nothing has worked. I have googled and have found advice using all the things I have tried. Do I have to post-process the generated list?
What have I missed?
I have 3 rules for dealing with DateTimes that served me well:
Always store, retreive and transmit the UTC value. Translating into the proper local Timezone is the job of ToString(), wich asks Windows for the users timezone. You do not want to add timezones to your troubles.
Avoid store, retreive or transmission of DateTimes as strings. Keep it in proper types whenever possible
If you can not follow rule 2 (like when you deal with Serialsiation), at least pick a fixed Culture Format and String encoding on all endpoints. You do not want to get different Cultures or faulty implied Encodings to your existing troubles
So, the answer to my issue had nothing to do with Linq or .Net. #JoeEnos put me on the right track as mentioned in my comment to his comment. I had created a class to receive each row of query result. The date fields were initially DateTime types but I started having issues. I changed those fields to string and then ended up asking my question above.
Back when the receiving class still had the DateTime fields, all of the fields had lowercase names. I must have applied some sort of code formatting that CamelCased the field names. This meant that after serializing the results the CamelCased names could not be found and the javascript didn't care.
I fixed the field names in my js code, changed the field data types back to DateTime and all is good.
Thanks
I have some nodes in a collection with a Date Time:
I query this using the C# cypher client thus:
GraphClient _client = new GraphClient(new Uri(url));
DateTime dt;
_client.Cypher
.Match("(e:LineStop)")
.Where((LineStop e) => e.AddedToDataWarehouse == false && e.TimeCreated >= dt)
.AndWhere((LineStop e) => e.Duration >0)
.Return<LineStop>("e")
.Results;
This works.
How can I do the same thing using the standard web based Neo4j Graph client? I can't seem to get the syntax to work at all.
All of the existing Q&As seem to talk about structuring the data differently to be more graph like and use shortestPath. I can't do this. The data already exists. I did not design this system nor do I have the abillity to change it.
I was told by the person that did design this system (a contractor who is no longer with the company) that Neo4j now supports dates(as opposed to stringfying them). On some level it must, or else how does the C# code work, right?
The C# code is treating the Dates as strings, if you look at what is being sent over the wire (using Fiddler), you'll see the JSON has it all escaped. Importantly, it's treating it as ISO format, which is sortable. If you chose to store them using US/UK format, you'd quickly find the comparison doesn't work.
The comparison is being done by Neo4j - example cypher showing the situation you have is here:
MATCH (n) RETURN
CASE WHEN ("2017-03-19T08:12:17.9680461+00:00" > "2017-03-20T08:12:17.9680461+00:00") = true
THEN "TRUE"
ELSE "FALSE"
END
If you put that into your browser, you'll get FALSE.
Your query isn't working as you are doing a string comparison and '2017-03-17' is not the same as the actual string you have created. Of the two options below - the adding of a property is the best route - and doesn't involve changing the structure of the graph, but obviously depends on the ability to set a property on the node.
If you can't add extra properties to the objects
To do a 'Between' style approach -
You have to pass in a fully defined DateTimeOffset string example: 2017-03-19T08:12:17.9680461+00:00
To do an equality comparison (with just the date specificied)
Use STARTS WITH as #InverseFalcon said
This is awkward as a full DTOffset string is long and unwieldy :/
If you can add a property
I would add a Ticks version of the DateTime properties, i.e. have a property called TimeCreatedTicks which is simply the .Ticks property of the TimeCreated property. This is my general route for storing Dates.
For manual querying this is still a pain as you need to know the Ticks for a given date - and that (for me at least) normally involves going to LinqPad and running new DateTime(2017,3,17).Ticks.Dump()
It looks like you need a string split function:
match (l.LineStop)-[:Creates]->(ls.LineStop)
where l.Name = 'M-E' AND
split(ls.TimeCreated, 'T')[0] = '2017-03-17'
return l, ls limit 100
In this case a STARTS WITH predicate should do the trick:
match (l.LineStop)-[:Creates]->(ls.LineStop)
where l.Name = 'M-E' AND ls.TimeCreated starts with '2017-03-17'
return l, ls limit 100
I am translating some C#-code to Java, and have chosen JodaTime's DateTime class, to replace C#'s System.DateTime.
In C# the DateTime class has a Field called MaxValue and one called MinValue, which returns the biggest and smallest possible value that the DateTime object can hold.
I am trying to achieve the same with the JodaTime api. I have read some suggestions on other posts
This one: Java equivalent of .NET DateTime.MinValue, DateTime.Today answers how to make today's date in JodaTime, but when answering the second half of the question, about Min Values, they turn to Calendar and Date
Likewise I have seen suggestions about passing a maximized long value as constructor parameter, but it was criticized for being dependant on classes that might be changed in the future, and therefor might not be compatible or accurat after API updates.
So, is there a single positively correct way to do this? If not, is there a good way to achieve this?
Java 8 LocalDate has two values. LocalDate.MAX and LocalDate.MIN
LocalDate.MAX - The maximum supported LocalDate, '+999999999-12-31'. This could be used by an application as a "far future" date.
LocalDate.MIN - The minimum supported LocalDate, '-999999999-01-01'. This could be used by an application as a "far past" date.
Note: these do not translate to Long.MIN_VALUE or Long.MAX_VALUE.
I suggest using Java 8 if migrating from C# and how date/time works is important to you, as it has closures AND a new DateTime API based on JodaTime. This new DateTime API is the one you should be using if you are worried about the future of an API.
I think you can assume that Long.MIN_VALUE and Long.MAX_VALUE will never change as they are based on the definition of how a signed 64-bit values work. (How 64-bit values work was standardised before you were born, most likely) You can also assume that Date will not change as it hasn't change much since it was released and since it has been replaced there is even less reason to change it. In theory it might be deprecated, but in reality there is still too much code which uses it.
IMHO, I use long to represent a time in milli-seconds ala System.currentTimeMillis() and I use Long.MIN_VALUE and Long.MAX_VALUE.
If you are concerned about using good API and future proofing your code, I suggest you avoid using Calendar. Not that it is all bad, but there are good reasons to want to replace it.
I found very confusing when sorting a text file. Different algorithm/application produces different result, for example, on comparing two string str1=";P" and str2="-_-"
Just for your reference here gave the ASCII for each char in those string:
char(';') = 59; char('P') = 80;
char('-') = 45; char('_') = 95;
So I've tried different methods to determine which string is bigger, here is my result:
In Microsoft Office Excel Sorting command:
";P" < "-_-"
C++ std::string::compare(string &str2), i.e. str1.compare(str2)
";P" > "-_-"
C# string.CompareTo(), i.e. str1.CompareTo(str2)
";P" < "-_-"
C# string.CompareOrdinal(), i.e. CompareOrdinal(w1, w2)
";P" > "-_-"
As shown, the result varied! Actually my intuitive result should equal to Method 2 and 4, since the ASCII(';') = 59 which is larger than ASCII('-') = 45 .
So I have no idea why Excel and C# string.CompareTo() gives a opposite answer. Noted that in C# the second comparison function named string.CompareOrdinal(). Does this imply that the default C# string.CompareTo() function is not "Ordinal" ?
Could anyone explain this inconsistency?
And could anyone explain in CultureInfo = {en-US}, why it tells ;P > -_- ? what's the underlying motivation or principle? And I have ever heard about different double multiplication in different cultureInfo. It's rather a cultural shock..!
?
std::string::compare: "the result of a character comparison depends only on its character code". It's simply ordinal.
String.CompareTo: "performs a word (case-sensitive and culture-sensitive) comparison using the current culture". So,this not ordinal, since typical users don't expect things to be sorted like that.
String::CompareOrdinal: Per the name, "performs a case-sensitive comparison using ordinal sort rules".
EDIT: CompareOptions has a hint: "For example, the hyphen ("-") might have a very small weight assigned to it so that "coop" and "co-op" appear next to each other in a sorted list."
Excel 2003 (and earlier) does a sort ignoring hyphens and apostrophes, so your sort really compares ; to _, which gives the result that you have. Here's a Microsoft Support link about it. Pretty sparse, but enough to get the point across.