We Keep Coding

How do I split a string in 2 with a colon in? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 17 days ago.
This post was edited and submitted for review 17 days ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
I have a textbox with an entry field, in which a user inputs time in a 00:00 format (HH:mm). What I would like to do is extract 2 integers from the string, the Hours (20:00 = 20 hours) and the minutes (00:20 = 20 minutes).
To clear things up, I tried using the string.Split() method with ":" as my delimiter. I was fetching my string from a TextMeshProUGUI Input Field in unity and when Split(); the resulting substring wouldn't convert into an Integer for some reason so I settled on using 2 separate (LEGACY) InputFields, one for hours one for minutes which works but is clunky.
I'm going to re-try my single InputField using the Legacy UI and the string.Split() method explained here.

Extending my comment into an answer. It seems like you're about to parse a string into a time which you can achieve with TimeSpan class and extract needed informations easily. For that you need to know what format your time input is and how you want to process it. Judging by your code I can assume you always expect a format of hh:mm which indicates that first part is an hour in 2 digit format ( either 02:mm or 14:mm ), same with minutes. This alone solves most of your problems because you can just parse your string into TimeSpan using ParseExact method:
// first, create a format you want to be used
const string FORMAT = "hh:mm";
// now just use TimeSpan.ParseExact method to retrieve your data
var result = TimeSpan.ParseExact(YourTextBoxText, FORMAT);
This will return a TimeSpan which has properties like Hours, Minutes etc. which you can then use to retrieve whatever time value you want.
EDIT: Things to note are that the above can throw a bunch of exceptions depending on the data input, formats etc. It's up to you if you're about to make any custom logic based on exception or whatever. Exceptions you might need to include in your logic and be aware of are
ArgumentNullException - thrown whenever argument is null,
FormatException - thrown whenever text input is in invalid format
For more info about TimeSpan you shold refer to the documentation

You could use the TimeSpan.Parse() function to convert the string to a TimeSpan.
Not the fastest method, but it's clean.
string time = "20:20";
if (TimeSpan.TryParse(time, out TimeSpan timespan))
{
// Do something with:
// timespan.Hours
// timespan.Minutes
}

Why does DateTime.Parse() get wrong year when parsing dd-MMM date? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I created an application in which the user enter a month-year dd-MMM date as input, and this date is parsed using the DateTime.Parse() method. It is working fine on my PC.
Dim txtDate as String = combobox1.Text
Dim dtDate as DateTime = DateTime.Parse(txtDate)
Example:
DateTime.Parse("01-Dec")
Result:
2017-12-01 00:00:00
But when running this application on other machines, it returns 1899 year.
1899-12-01 00:00:00
After searching I found a similar question here: Time parsing Issue using DateTime.ParseExact() and it is marked as answered, but there is no solution for this situation
Does anyone knows what causes this problem?
Note: it is an old application I am working on. I know that it is recommended to replace it with a DateTime picker, but the issue is very confusing

Date.Parse without specifying an IFormatProvider will use the current user's Culture settings to determine what formats to parse, so 01/04/2017 will be 2017-April-01 on most computers (dd/MM/yyyy) but 2017-Jan-04 on computers in the US (MM/dd/yyyy).
If you're using the same format everywhere, you should use DateTime.ParseExact and provide an explicit format.
As for your specific problem, the string 01-Dec does not specify a year component, the computer must therefore infer the date, and how that date is inferred is often down to the Culture setting too.

DateTimeFormat issue [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
I have a string like below
1/1/1970 12:00:00 AM
I want it in the yyyy-MM-dd format (in this case 1970-01-01)
My parsing code is
var actualDate = DateTime.ParseExact(actualValue,"MM/dd/yyyy HH:mm:ss tt",CultureInfo.InvariantCulture).ToString("yyyy-MM-dd");
But I keep getting the error, that the string is not recognized as a valid date time.
I looked at my variable actualValue and it is of type DateTime, so am thinking that the problem is with the format MM/dd/yyyy HH:mm:ss tt ,What is wrong with this?

First, you shouldn't be storing or fetching dates as text in the DB.
To your specific issue, however, MM and dd are the two-digit variety of month and day. Obviously your date text doesn't use the two-digit-only variety, so use M and d. Also, HH is on a 24-hour clock. Using tt, which is AM/PM, would imply not having a 24 hour clock, so you would want to use hh instead.
For more, look at MSDN for custom date/time formatting.

set Date & time regular expression to RegularExpressionValidator according to culture [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am facing a problem of validating date & time according to local culture.
This is my RegularExpressionValidator
<asp:RegularExpressionValidator
ID="regTime"
ControlToValidate="txtTime"
Display="Dynamic"
Text="Invalid Time Format"
ValidationExpression="^((1[012])|(0?[1-9])):([0-5][0-9]) ?([aApP][mM])$"
runat="server">
</asp:RegularExpressionValidator>
The above validator validates time of en-en culture.
Now as I am developing an applications which needs to be able to handle date and time format of every culture, I want a concrete solution to how to validate date & time depending on culture using RegularExpression.
For example, American time format is h:mm tt (01:20 PM) & German time format is HH:mm (13:20).

Sorry but this reminds me of the popular quote:
Some people, when confronted with a problem, think "I know, I'll use
regular expressions." Now they have two problems.
Anyway, you don't need regular expressions for this. .NET's DateTime and CultureInfo are best suited to solve this. Create your own custom validator that does something like the following:
var usCulture = new CultureInfo("en-us");
DateTime.ParseExact("3:20 PM", usCulture.DateTimeFormat.ShortTimePattern, usCulture);
var germanCulture = new CultureInfo("de");
DateTime.ParseExact("13:20", germanCulture.DateTimeFormat.ShortTimePattern, germanCulture);
Use DateTime.TryParseExact if you want a return value instead of an exception.

Why does the ISO-8601 specification appear to be universally ignored when it comes to decimals? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
From the ISO-8601:2004(E) Specification:
4.2.2.4 Representations with decimal fraction
If necessary for a particular application a decimal fraction of hour, minute or second
may be included. If a decimal fraction is included, lower order time
elements (if any) shall be omitted and the decimal fraction shall be
divided from the integer part by the decimal sign specified in ISO
31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the
preferred sign.
Simple enough. So according to this spec, fractions of a second are preferred to be written using a comma separating the whole and decimal parts, such as 2014-01-01T00:00:00,123. However it seems that just about everywhere, only a decimal point (aka "full stop") is accepted!
Now I'm sure there are some languages or libraries that took this into account, and I know in many cases you can supply the full details of the format yourself. But it seems like such a glaring oversight of the specification and it appears that a wide variety of programmers have made the same mistake. Is there a reason why this is the case, other than pure human error?
Below is a list of where I tested. Feel free to edit the question to augment my list if you find any others. Thanks.
.NET / C#
DateTime dt = DateTime.Parse("2014-01-01T00:00:00,123");
Throws a FormatException with the message "String was not recognized as a valid DateTime". The same thing with a period instead of a comma parses successfully.
JavaScript Date Object
Tested in latest (as of this writing) Chrome, Internet Explorer, Firefox and Node.js:
var dt = new Date('2014-01-01T00:00:00,123');
Returns "Invalid Date". Using a period instead works fine.
JavaScript with moment.js
var valid = moment("2014-01-01T00:00:00,123").isValid();
Returns false. Using a period instead returns true.
PHP
echo strtotime('2014-01-01T00:00:00,123');
Returns an empty string. Using a period instead works fine.
Ruby
require 'time'
puts Time.iso8601("2014-01-01T00:00:00,123")
Gives a runtime error. While Time doesn't keep fractional seconds, it shouldn't error - and indeed if a period is used instead, it works.

RFC3339, as defined by the IETF specifies only the . as a delimiter.
Here's section 5.6:
5.6. Internet Date/Time Format
The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
new protocols on the Internet. This is specified using the syntax
description notation defined in [ABNF].
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
; rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset
date-time = full-date "T" full-time

A pure ISO-8601-compliant parser MUST support both comma and dot. The comma is not strictly required, only recommended. So regarding this standard the given examples of JavaScript, PHP, Ruby etc. clearly indicate an error of those parser implementations.
RFC3339 indeed only supports a subset (excluding the comma AND also excluding decimal hours or decimal minutes!) - so not fully ISO-compliant.
XML-schema is similar. It excludes the comma, unfortunately (see the W3C-document).
So you ask why? That is my suspicion: Programming world is strongly dominated by US. In US culture the dot is used as decimal separator in numbers. So most people developing such frameworks, standards and libraries are sitting in US and mistakenly think that dots are quasi an international standard.
So the question remains, why ISO uses/recommends the comma? I don't know it exactly, but we all know the office of ISO group is located in Paris, not in US. And in Europe (excluding UK) the comma is generally preferred as decimal separator, also a cultural aspect.
Finally, not all parsers are wrong. At least Joda-Time supports comma, too, although preferring the dot in printing. What is the situation in NodaTime? I hope at least similar to Joda-Time. Please keep supporting parsing of comma. From an european perspective it is nice to see that not all stuff looks like american ;-).