[RESOLVED] The problem with Dating

[BasicBasic]

I have seen a large number of ideas on how to generate a DATE of type Date without all of the conversion from English Format to US format and the inclusion of TIME included
Dim testDate As String = "01/10/2019" produces: "01/10/2019", perfect
However converting the string into a DATE Type, never seems to work, no matter what I have tried.

Example:
Dim testDate As Date = CDate("01/10/2019"), produces: #10/1/2019 12:00:00 AM#, which is not what I wanted. Also, I don't know if the 12:00:00 AM is actually used by the code or is just there for my information, Phantom text.

Dim testDate As Date = CDate("01/10/2019").ToShortDateString, produces the same result

Dim testDate As String = "01/10/2019"
Dim expenddt As Date = Date.ParseExact(testDate, "dd/MM/yyyy", System.Globalization.DateTimeFormatInfo.InvariantInfo)
Produces: #10/1/2019 12:00:00 AM#, which is no better that any of them

What I need is: Dim testDate As Date = Function("01/10/2019") and get back the testDate result as: expenddt | "01/10/2019" when I perform a Mouse Over in Visual Studio...No date transformation
No date transformation
No Time
No AM/PM nothing but: Date (as type string) "01/10/2019" to Date (as Type Date) "01/10/2019"

Question:
Is this achievable and how.

The reason I am interested in doing this is because I am HASHing a Date. I cannot UnHASH the date, but I do know what the range of of the dates are. If I have an arrayDates(4000) and HASH each one separately, I can compare the original HASH and therefore find what the Date was.

Need help Y'All

[Goggy]

If you can work with strings... You could always format the date in the correct way, like so

        Dim D As Date = CDate("01-01-2009")

        Debug.Print(D.ToString("dd-MM-yyyy"))

[ChrisE]

Hi

like this perhaps

 Private Sub Button2_Click(sender As System.Object, e As System.EventArgs) Handles Button2.Click
        Dim d As Date = New Date(2019, 1, 10)
        Dim dateValue As Date = d
        MsgBox(d.ToString("dd.MM.yyyy"))
    End Sub

[techgnome]

If you can work with strings... You could always format the date in the correct way, like so

        Dim D As Date = CDate("01-01-2009")

        Debug.Print(D.ToString("dd-MM-yyyy"))

Ummm.... no.... format and value are not the same thing.. that's what the OP is having issues with. One isn't the other.

@OP - Date inherently have a time component... that's why you see the 12:00:00AM ... Again, as I just mentioned, don't confuse the value with the display. As for the month/day flipping ... dates are a funny animal... 1/10/2019 ... is that Jan 10, 2019, or Oct 1, 2019? Depends on where in the world you are. One solution is like what ChrisE showed... another is to use an ISO format: yyyy-mm-dd then there is no ambiguity.

What I need is: Dim testDate As Date = Function("01/10/2019") and get back the testDate result as: expenddt | "01/10/2019" when I perform a Mouse Over in Visual Studio...No date transformation
No date transformation
No Time
No AM/PM nothing but: Date (as type string) "01/10/2019" to Date (as Type Date) "01/10/2019"

Ahhh... so.... yeah, you're out of luck there then. A date is a date, and it's going to have a time component, that's just the way it is. And as far as to the format, that is up to your system's regional settings - I think... or it's just simply the way VS displays it, but it shouldn't matter. Aagain, let me iterate the important thing to learn about this, don't confuse the value of the data with the display format of the date. The display format is just that, the display format.

-tg

[si_the_geek]

The safe simple and flexible way to create a date value is as ChrisE showed... you can always be sure it will create the value without misinterpreting months etc, and you can use variables for the year etc if you want.

As far as values being displayed with times, Date and DateTime always contain a time component, and whether or not the time is displayed is something you can only control if it is your code and you use .ToString() with an appropriate format. As things like a Mouse Over in Visual Studio are dealt with by code that isn't yours, you can't control it there.

[Goggy]

(Just because I'm stubborn)

I tried, in my bad words, to say that if you can use a string as input in Hash function. It is no problem that a Date variable always has a time component. You can then format the date in the way that you need.

(I hope I have clarified myself a bit, and sorry for my poor English ... have a Dutch keyboard ;-))

[si_the_geek]

I tried, in my poor wording, saying that if you can use a string as input to hash function. It is no problem that a Date variable always has a time component. You can then use the date format in the way that you need.

(I hope I've explained myself a bit, and sorry for my poor english ... have a Dutch keyboard ;-))

The .ToString() part was correct, but the CDate() part wasn't... unfortunately creating a date value isn't as simple as it could be.

If the initial value is a String then using Date.ParseExact as BasicBasic tried was the right way to go, but I don't have time at the moment to check why it didn't work.

[Goggy]

Ahhh, ok i understand. :-)
Thanks si_the_geek

[techgnome]

Even the .ToString wasn't really right (in this case)... I went back over the OP's post as I was composing my reply, and as I understand it, his issue is the intellisense tool tip that pops up with a variable's value when you mouse over during debugging... so a .ToString wouldn't affect that. In a way, I see where he's coming from - if you set an integer to 1, you get 1... not 1.00000 ... or some other value. So the expectation is that if you set a datwa variable to 1/10/2019, that that's what you'd see... but... dates don't play by the same rules, they have their own set of rules, so that expectation goes out the window and down the street. .ToString would only have any bearing when displaying it to the user, but I don't think that's what the OP was after in this case. Which is why I quoted part of his post which included "Mouse Over in Visual Studio" ... That's when I realized it's the tool tip during debugging that shows the variable values that he's on about... and honestly, I don't remember if that's controlled by the computer's local regional settings or not. But... either way, it still displays the time because time is a component of date, not matter what.


-tg

[BasicBasic]

OK I agree. The problem might be what is being displayed with Visual Studio (mouse over) is not necessarily the actual value being used in code. If this is true, then what is being displayed is then actuall wrong. What should be displayed is "the value" that will be used in the code.

As my task is to be able to compare dates that have been HASHED, it is important that the actual VALUE is identical or the HASH will not match. I did the following as a test:
Dim testDate As String = "01/10/2019"
Dim expenddt As Date = Date.ParseExact(testDate, "dd/MM/yyyy", System.Globalization.DateTimeFormatInfo.InvariantInfo)
Dim startdate As String = expenddt.ToShortDateString
Dim arrayHASHdate(4000) As String
testDate = GenerateSHA256String(testDate)
startdate = GenerateSHA256String(startdate)

What I found was that the values of testDate and startdate HASH values were identical, so maybe there is not a problem in the end...what do you think Y'All

[si_the_geek]

These two lines:

Dim testDate As String = "01/10/2019"
Dim expenddt As Date = Date.ParseExact(testDate, "dd/MM/yyyy", System.Globalization.DateTimeFormatInfo.InvariantInfo)

...would be better (less code, more reliable, less work for the code to do at run-time) like this:

Dim expenddt As Date = New Date(2019, 10, 1)

(this gets Oct 1st, swap the 1 and 10 if you wanted Jan 10th)


This line:

Dim startdate As String = expenddt.ToShortDateString

...generates an unpredictable result, because it is based on things outside of your control (such as the Regional Settings of the computer that your program is running on). It is fine to use that for displaying values to the user, but not in the kind of situation you have - when you want the string to be in a particular format, you need to specify it, eg:

Dim startdate As String = expenddt.ToString("dd/MM/yyyy")

What you should be doing is something like this initially:

  Dim dateValue As Date = New Date(2019, 1, 10)  'or possibly:   = DateTime.Now
  Dim dateValueFormatted as String = dateValue.ToString("dd/MM/yyyy")
  Dim dateValueHashed as String = GenerateSHA256String(dateValueFormatted)

...then store the hash.

To compare another value against the hash, generate the hash for the other value in the same way.

[dbasnett]

Some testing with different cultures.

        Debug.WriteLine("")

        Dim dutch As New Globalization.CultureInfo("nl")
        Dim USA As New Globalization.CultureInfo("en-US")

        'the next two date declarations produce the same date
        ' because of the constructor used.
        Dim dD As Date = New Date(2019, 1, 10, dutch.Calendar)
        Debug.WriteLine(dD.ToString("dd MMM yyyy"))

        Dim dU As Date = New Date(2019, 1, 10, USA.Calendar)
        Debug.WriteLine(dU.ToString("dd MMM yyyy"))

        'the next two date declarations produce different dates
        ' because they are parsed using different cultures
        Dim d1 As Date = Date.Parse("1/10/2019", dutch)
        Debug.WriteLine(d1.ToString("dd MMM yyyy"))

        Dim d2 As Date = Date.Parse("1/10/2019", USA)
        Debug.WriteLine(d2.ToString("dd MMM yyyy"))

        Debug.WriteLine("")
        Debug.WriteLine(dutch.Name)
        Debug.WriteLine(dutch.DisplayName)

        Debug.WriteLine("")
        Debug.WriteLine(USA.Name)
        Debug.WriteLine(USA.DisplayName)

        Debug.WriteLine("")
        Debug.WriteLine(Globalization.CultureInfo.CurrentCulture.Name)
        Debug.WriteLine(Globalization.CultureInfo.CurrentCulture.DisplayName)
        Stop

[BasicBasic]

...interesting, I have not seen: Dim dateValueFormatted as String = dateValue.ToString("dd/MM/yyyy") before. It appears as though the evolution of VB has lead to many changed to Code Functions. As this is my first VB program (I am an Embedded ANSI_C guy), I find Functions all over the YouTubs and Microsoft web that go back 7-years and things keep improving, but they maintain the legacy...good AND BAD.
I will give this some testing and send every the results...thanks everybody.

[BasicBasic]

I did get an error for: Dim dateValueFormatted as String = dateValue.ToString("dd/MM/yyyy") I think something might be missing. Can you correct please
ERROR: System.InvalidCastException: 'Unable to cast object of type 'System.String' to type 'System.IFormatProvider'.'

[Shaggy Hiker]

...interesting, I have not seen: Dim dateValueFormatted as String = dateValue.ToString("dd/MM/yyyy") before. It appears as though the evolution of VB has lead to many changed to Code Functions. As this is my first VB program (I am an Embedded ANSI_C guy), I find Functions all over the YouTubs and Microsoft web that go back 7-years and things keep improving, but they maintain the legacy...good AND BAD.
I will give this some testing and send every the results...thanks everybody.

That one has been around for as long as I can remember (and I can remember a long time...usually....now, where was I....?). Interestingly, I find the fact that .ToString can take arguments to be relatively poorly documented. I know it's there, so when I want to look up the options for the arguments, I know what to search for, but I can't say I've ever encountered it by accident, which kind of means that you need to know it's there to know what to look for.

One thing about VS is that items in debugging (tooltips, or Shift+F9) will display the object with .ToString called on it. I found that one out the hard way. Normally, .ToString does just what you'd like. However, you can override ToString for your own objects, and if you do that just right, the tooltips will end up getting in the way. In your case, a date.ToString shows the full contents of the date structure, which includes both date and time. This is reasonable, as a date is really a point in time, whether you care about the time or not, and if you don't care about the time, you get 12:00:00 AM. That's what .ToString() for a date returns, so that's what VS will show you in tooltips and the like.

Of course, dates may be the hardest single thing to solve in all of programming.

[BasicBasic]

That one has been around for as long as I can remember (and I can remember a long time...usually....now, where was I....?). Interestingly, I find the fact that .ToString can take arguments to be relatively poorly documented. I know it's there, so when I want to look up the options for the arguments, I know what to search for, but I can't say I've ever encountered it by accident, which kind of means that you need to know it's there to know what to look for.

One thing about VS is that items in debugging (tooltips, or Shift+F9) will display the object with .ToString called on it. I found that one out the hard way. Normally, .ToString does just what you'd like. However, you can override ToString for your own objects, and if you do that just right, the tooltips will end up getting in the way. In your case, a date.ToString shows the full contents of the date structure, which includes both date and time. This is reasonable, as a date is really a point in time, whether you care about the time or not, and if you don't care about the time, you get 12:00:00 AM. That's what .ToString() for a date returns, so that's what VS will show you in tooltips and the like.

Of course, dates may be the hardest single thing to solve in all of programming.

I agree, as I called the name of this thread..."I have always had problems with Dating"...lol, thanks for all your kind attention to my problems.

[BasicBasic]

It looked like:
Dim d2 As Date = Date.Parse("1/10/2019", USA)
would be perfect, if I could specify: Dim d2 As Date = Date.Parse("1/10/2019", UK), for instance.

Unfortunately, both USA and UK both cause Compile Errors. Do you have a corrective syntax for me to try...thanks for your help.

[si_the_geek]

USA was included in the example you got that from, UK isn't much different (en-GB).

I did get an error for: Dim dateValueFormatted as String = dateValue.ToString("dd/MM/yyyy") I think something might be missing. Can you correct please
ERROR: System.InvalidCastException: 'Unable to cast object of type 'System.String' to type 'System.IFormatProvider'.'

That is odd, I just tested in Fiddle it worked, but there may be a difference between that environment and yours.

Here is an alternative version of that line:

Dim dateValueFormatted as String = dateValue.ToString("dd/MM/yyyy", CultureInfo.InvariantCulture)

(you may need to add Imports System.Globalization to the top of the code file)

[dbasnett]

USA was included in the example you got that from, UK isn't much different (en-GB).


That is odd, I just tested in Fiddle it worked, but there may be a difference between that environment and yours.

Here is an alternative version of that line:

Dim dateValueFormatted as String = dateValue.ToString("dd/MM/yyyy", CultureInfo.InvariantCulture)

(you may need to add Imports System.Globalization to the top of the code file)

@BasicBasic To add to what si_ said. Did you copy the example I gave? Did it work unaltered?

[Shaggy Hiker]

I agree, as I called the name of this thread..."I have always had problems with Dating"...lol, thanks for all your kind attention to my problems.

This is the wrong forum to get help coders with dating.

[BasicBasic]

Ummm.... no.... format and value are not the same thing.. that's what the OP is having issues with. One isn't the other.

@OP - Date inherently have a time component... that's why you see the 12:00:00AM ... Again, as I just mentioned, don't confuse the value with the display. As for the month/day flipping ... dates are a funny animal... 1/10/2019 ... is that Jan 10, 2019, or Oct 1, 2019? Depends on where in the world you are. One solution is like what ChrisE showed... another is to use an ISO format: yyyy-mm-dd then there is no ambiguity.



Ahhh... so.... yeah, you're out of luck there then. A date is a date, and it's going to have a time component, that's just the way it is. And as far as to the format, that is up to your system's regional settings - I think... or it's just simply the way VS displays it, but it shouldn't matter. Aagain, let me iterate the important thing to learn about this, don't confuse the value of the data with the display format of the date. The display format is just that, the display format.

-tg

I see...I will probably have to just accept this as VB is not likely going to be overhauled into sanity, but I must say in closing this thread, that if I FORMAT(...something in here...),("dd/MM/yyyy") and clearly state that I want the UK formatting and I am using a computer in the UK with the system date set to GMT and then...when I mouse-over the variable I get something like: 10/30/2019 as the date...something is wrong.

RECAP:
As Visual Basic is refusing to acknowledge the format I am setting, it makes debugging very difficult, because I cannot check what the format is. Example: If I have established an arrayDate(10) that I have attempted to set to the format "dd/MM/yyyy" and I am going to compare this to a checkDate = "30/10/2019", I the code cannot find a match, how can I verify that I am not checking the checkDate to an array set to the format "MM/dd/yyyy"? what if the date was 12/10/2019 is this December or October. Without knowing FOR SURE what the formatting is, do we assume that if we set a format to "dd/MM/yyyy" then it is going to be October, no matter what Visual Studio tells me?

You also raised another interesting question...If my application is going to use my system date is it impossible for me to use this application on systems set to the USA format. I must be able to establish "THIS IS THE FORMAT I WANT", don't use anything else, right. What do I need to do to cover my demographics?

I apologize for this overly long reply...very sincere thanks.

[ChrisE]

well as long as you where that Date is coming from
you can convert it to your Date
and as Shaggy said in Post#15 ..as a date is really a point in time...

here a sample to Convert a DateTime value from the US to German Datetime

Friend Function ConvertDateTimeToCulture(ByVal sDateTime As String, _
      ByVal NameInputCulture As String, _
      ByVal NameOutputCulture As String) As String

        Dim InputCulture = New System.Globalization.CultureInfo(NameInputCulture)
        Dim OutputtCulture As CultureInfo = _
          CultureInfo.CreateSpecificCulture(NameOutputCulture)
        Dim oCurrentCulture As CultureInfo = _
          System.Globalization.CultureInfo.CurrentCulture

        ' Culture des Threads entsprechend des Eingabe-Datums einstellen
        Thread.CurrentThread.CurrentCulture = InputCulture

        Dim temp As DateTime = DateTime.Parse(sDateTime, _
          InputCulture, DateTimeStyles.NoCurrentDateDefault)
        Thread.CurrentThread.CurrentCulture = OutputtCulture

        ' Umgewandelte DateTime als String zurückgeben
        ConvertDateTimeToCulture = temp.ToString

        ' Culture des Threads wieder zurückstellen
        ' (sonst würde das Programm weiter mit der OutputCulture laufen)
        Thread.CurrentThread.CurrentCulture = oCurrentCulture
    End Function


    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim sNewDateTime As DateTime
        sNewDateTime = ConvertDateTimeToCulture("7/17/2018 8:51:33 PM", "en-US", _
          System.Globalization.CultureInfo.CurrentCulture.Name)
        
Debug.Print(sNewDateTime) ' 17.07.2018 20:51:33
       
 Label1.Text = sNewDateTime

    End Sub

hth

[si_the_geek]

VB isn't lacking sanity, it is just dealing with the real world in a way that isn't intuitive to you.

The only data type that has a format is a String.

Other data types (numbers, dates, etc) only have a value, and they only get a format when you convert them to a String... which is why in the code I posted the variable dateValueFormatted is a String.

Unfortunately the tooltips etc in Visual Studio for non-String values use US format, and while that is a bit annoying it is somewhat justifiable, and something you get used to.

if I FORMAT(...something in here...),("dd/MM/yyyy") and clearly state that I want the UK formatting and I am using a computer in the UK with the system date set to GMT and then...when I mouse-over the variable I get something like: 10/30/2019 as the date...something is wrong.

The thing that would be wrong there would be your code... because you haven't stored the result of the Format to a String.

If you want to set a date value, don't use a String to do it unless you have to (because that adds complications, and involves jumping thru extra hoops to get to the same place). The following code will always create a date value of Oct 1st:

  Dim dateValue As Date = New Date(2019, 10, 1)

(and while you are typing it, Visual Studio will remind you of which part is the month, etc)

You also raised another interesting question...If my application is going to use my system date is it impossible for me to use this application on systems set to the USA format. I must be able to establish "THIS IS THE FORMAT I WANT", don't use anything else, right. What do I need to do to cover my demographics?

Once you have got your mind around a Date being different from a String (and write code appropriately), the computer settings are only relevant if/when you want them to be.

[Shaggy Hiker]

Another way to put it is that a Date is a structure. Like most structures, it has a series of fields. You can see those fields, but the key fields are year, month, day, hour, minute, and second. There are also methods, and almost certainly some operator overloads, as well, though I haven't looked.

So, you are thinking of the date as the string that you see it displayed as (all displayed text is a series of characters, so it must be a string, no matter what the data in that string resembles), but a date is still just a structure. Whether you are UK or US, it really doesn't matter to the structure. The Month property holds the month and the Day property holds the day. When you display that date, if you are UK, then the day will show first, followed by the month. If you are US, then the month will show first, followed by the day. The properties aren't changing their value, all that is changing is the order in which they are used to build the display string.

This is kind of important for working with dates. The Date structure holds the elements that are required to hold the information, without regard to where it is located, which is what's important. Without that, you'd have a heck of a time dealing with all the vagaries of time zones, let alone the different ways that date can be displayed. With that, you can show any particular date in any particular time zone or format. You don't have to be thinking about whether month or date comes first, or whether the time zone is this or that. The Date structure just holds the data. What you do with it is up to you.

[BasicBasic]

VB isn't lacking sanity, it is just dealing with the real world in a way that isn't intuitive to you.

The only data type that has a format is a String.

Other data types (numbers, dates, etc) only have a value, and they only get a format when you convert them to a String... which is why in the code I posted the variable dateValueFormatted is a String.

Unfortunately the tooltips etc in Visual Studio for non-String values use US format, and while that is a bit annoying it is somewhat justifiable, and something you get used to.

The thing that would be wrong there would be your code... because you haven't stored the result of the Format to a String.

If you want to set a date value, don't use a String to do it unless you have to (because that adds complications, and involves jumping thru extra hoops to get to the same place). The following code will always create a date value of Oct 1st:

  Dim dateValue As Date = New Date(2019, 10, 1)

(and while you are typing it, Visual Studio will remind you of which part is the month, etc)


Once you have got your mind around a Date being different from a String (and write code appropriately), the computer settings are only relevant if/when you want them to be.

If I establish an array of Dim myDates(10) I understand that they will be dates. However, If I have a Test File containing data and I want to compare a Dim mytextDate if I dont know the format of the myDates elements then when I convert them to a string and do a compare I have no way of knowing what is being compared. If I convert the mytextDate string variable to a date and make the compare, this will only work if the Date variable are always compared as a date no matter what the format is...is this what you are saying.

From what you said, I think I understand...
MY UNDERSTANDING:
In VB a Data is a Date and formatting does not enter into it. Formatting a Date into a String is for visualization only, right? So for my comparison, all I need to do is compare a Date Variable and not worry about the formatting because it does not matter internally...is this a correct understanding?

[Shaggy Hiker]

Yes, and it's likely to be faster. If you have dates in a text file, convert them to Date objects rather than converting the Date objects to strings and comparing that way. Not only does that get away from formatting questions, but you get a few tools that you may or may not care about. For example, you can subtract two Date objects and the result is a TimeSpan with a variety of useful items, such as the difference in days, or hours, or months, or whatever you want. You won't be doing that easily with stringy-dates.

Dates are pretty convenient as left as Dates. Once they are displayed as strings, they are much less convenient since you get to deal with display formatting and so forth.

[BasicBasic]

OK, I will ponder this a while. I do still think that Visual Basic should recognize the Date of the system and sync its Tool Tip accordingly. I also have an issue with Google Maps...even though I display a Map in the UK, Google Maps always shows a route going the wrong way around roundabouts, they so around Counter Clockwise, but I learned to live with ti. I will do the same with Visual Studio.

I do want to thank everybody for their generosity with my Thread, it is gratefully received...thanks Y'All

[dbasnett]

If you have dates that must be stored as strings it is up to you to do so in a way that can't be confused. As you've seen dates like '1/10/2019' can be interpreted differently depending on the culture.

Here is some test data, dates in a format that can't be confused.

18-Oct-2019
07-Nov-2019
27-Nov-2019
17-Dec-2019
06-Jan-2020
26-Jan-2020
15-Feb-2020
06-Mar-2020
26-Mar-2020
15-Apr-2020
05-May-2020
25-May-2020
14-Jun-2020
04-Jul-2020
24-Jul-2020
13-Aug-2020
02-Sep-2020
22-Sep-2020
12-Oct-2020
01-Nov-2020
21-Nov-2020
11-Dec-2020
31-Dec-2020
20-Jan-2021
09-Feb-2021
01-Mar-2021
21-Mar-2021
10-Apr-2021
30-Apr-2021
20-May-2021

Save that in a text file. Then give this code a try.

        Debug.WriteLine("")
        Dim path As String = "path to test file" '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
        Dim lns() As String = IO.File.ReadAllLines(path)

        Dim Dutch As New Globalization.CultureInfo("nl")
        Dim GB As New Globalization.CultureInfo("en-GB")
        Dim USA As New Globalization.CultureInfo("en-US")

        Dim dd As DateTime 'dutch
        Dim dg As DateTime 'great britain
        Dim du As DateTime 'usa

        For Each dt As String In lns
            'now create dates for each culture
            dd = Date.Parse(dt, Dutch)
            dg = Date.Parse(dt, GB)
            du = Date.Parse(dt, USA)
            'check if they are the same
            If dd <> dg Then
                Stop
            ElseIf dd <> du Then
                Stop
            End If
        Next

[Shaggy Hiker]

OK, I will ponder this a while. I do still think that Visual Basic should recognize the Date of the system and sync its Tool Tip accordingly.

I totally agree with that idea. It wouldn't have been very difficult for them to do, either. After all, they had to override the default .ToString just for you to get the value you are seeing, so overriding it to include localization seems pretty reasonable to me.

On the other hand, I've often wondered about foreign language speakers using VB. It's a fairly verbose language, but that language is English. If you don't read English, or speak it, how well does For Each translate to you? We do seem to leave biases in everything.

[BasicBasic]

Quite right Shaggy