[Wish] DateTime to Parse one String containing Both Date and Time

[Roger Garstang]

Moved this here to not clutter the 2.50 thread anymore. Last comment mentioned "without the need to create a combined format", but that isn't the problem. I don't create the combined format- it comes from the database combined.

MySQL gives me a DateTime like "2012-12-31 23:59:59". Other HTML formats are similar or may have a T like "2012-12-31T23:59:59" to show where the split is. None of the existing functions or the new function will process this way. I like keeping Date and Time together too otherwise the time portion will lose the link to the date and mess up Timezone and DST shifts.

Having a function to parse the full date and a 3rd Format variable to store the combined format and not interfere with the existing two would be ideal.

 

[Vader]

Pardon me if it looks like I'm teaching you to suck eggs, but depending on the system in use (SQL, MySQL, Windows etc), Dates are usually stored as a long(?), but are parsed as a String (either explicitly, or via the equivelant of the .NET .ToString() method).

Trying to be helpful here, and taking the above into account, isn't what you want to do is to have the equivelant of the .NET ToString(NamedFormat) method?
That way you could get any part of the date (and/or time) from the other system (SQL etc).

Or pardon my ignorance, is that what you are asking for?

EDIT: B4A already does this with the named formats available here:
SimpleDateFormat (Java 2 Platform SE v1.4.2)

 

[Roger Garstang]

I don't need toString values, I already have string values. The MySQL values come from DateTime fields which are given as strings as well as HTML forms which are also strings. You are thinking of Unix Timestamps/Epoch time or Timestamps in MySQL which I don't use. They usually start at a certain date- For Unix it is 1970. If 32bit then you run into limits. Android/Java uses 64bit, so I actually use them in my Android Databases. These string values read from MySQL, web, and even Android dialogs/fields need parsed and displayed. When storing, parsing, and displaying I keep date and time together as one field.

There have been some discussions in the past about processing this with DateTime in B4A. Many get confused by the naming and don't realize you can make the two formats whatever you want. You can make TimeFormat be a date string and when you Parse Time it really parses a date. Or you can make one of the Format strings be date and time and process it with one function. In a few threads I clarified this for users before and mentioned the naming was confusing. Many users need to process both and tried just concatenating on their own a lot and got it wrong with missing DST shifts and such from splitting time away from their date. A function was needed to process both, but I think Erel misunderstood the request and in 2.50 he made a new function to process both, but it does it by still keeping two strings and splitting time from date. It made the parsing easier by skipping a step and doing it in one function, but it is still doing it the same as before. It needs to process the parse with one string.

 

[corwin42]

I don't know if you have seen it but the AHLocale library has a AHDateTime object which can do all you need.

The internal DateTime object has some drawbacks:

1. it stores the pattern global so it is not thread safe.
2. it can't handle localized times/dates.
3. It is a static object so if you need to convert many different formats you need to change the pattern many times.

If I need very simple date calculations/formatting I use the internal object.
If I have to do more complex things with dates and times (like I have to handle time zone correctly) I use the AHDateTime object.
If you have to use Date/Time formatting/parsing in your own thread the internal object is a NoGo.

 

[Erel]

like I have to handle time zone correctly

Note that there are no time zone issues with DateTime. There were in the past and they were fixed.

 

[corwin42]

Note that there are no time zone issues with DateTime. There were in the past and they were fixed.

Yes, you are correct. I meant if I have to handle different time zones I think it is easier with AHLocale library (It has its own TimeZone object).
The main reason to change everything from DateTime to AHDateTime in my apps was the thread thing. I got very rare parse exceptions when the weather data was downloaded in the background. That was because the app was parsing date strings in the background and formatting other dates for refreshing the display at the same time.

 

[Erel]

Just to clarify for other members, threading errors can only happen if you use the Threading library. Now unless the strings are huge the parsing step will be very quick and will not slow down the app. Downloads are always done in the background.