Days

[AHMEDSULAIMAN]

DEAR ALL,
HOW CAN I GET THE NO OF DAYS IN A MONTH ?. iS THERE ANY SIMPLE FUNCTION OR FORMULA IN VB ?.



THANK YOU,


MA SULAIMAN

[dglienna]

This will print the last day of the current month:

Option Explicit
 
Private Sub Form_Load()
  Debug.Print DateSerial(Year(Now), Month(Now) + 1, -1)
End Sub

[AHMEDSULAIMAN]

THIS GIVES 30-MAR-2005.
i WANT TO PRINT NO OF DAYS IN A MONTH

THANK yOU,




wITH BEST REGARDS,
M A SULAIMAN.

[dglienna]

Option Explicit
 
Private Sub Form_Load()
  dim ld as date
  ld =  DateSerial(Year(Now), Month(Now) + 1, 0)
  msgbox day(ld) & " days in the month"
End Sub

Sorry, I had one too many subtracted

gives you the last day of the month

[AHMEDSULAIMAN]

Thank You very much.

[Habibi]

DEAR ALL,
HOW CAN I GET THE NO OF DAYS IN A MONTH ?. iS THERE ANY SIMPLE FUNCTION OR FORMULA IN VB ?.



THANK YOU,


MA SULAIMAN

Sulaiman, do u want to find out the number of days between two date's ?

Then you have to use the DateDiff Function: Here's an example;

Private Sub Command1_Click()
Dim DT as Variant
DT = DateDiff("d", txtDate1.Text, txtDate2.Text)
txtTotDays.Text = Format(DT, "00")
End Sub

[Simply Me]

Thank You very much.

Edit your first post and add [RESOLVED] to your title or just put check icon

[dglienna]

He wanted number of days in a month.

Your example is completely wrong. How does two dates tell you the number of days in a month? Put in today and tomorrow. dt=1 not number of days in a month.

You have to read the request, and then post a solution to that problem.

[Simply Me]

Sulaiman, do u want to find out the number of days between two date's ?

Then you have to use the DateDiff Function: Here's an example;

Private Sub Command1_Click()
Dim DT as Variant
DT = DateDiff("d", txtDate1.Text, txtDate2.Text)
txtTotDays.Text = Format(DT, "00")
End Sub

Hey Habibi. I was about to do something like that in my project. Thanks for the code. Saves me time figuring it out how to do it.

[Habibi]

u most welcome.

[szlamany]

In general, when a math function can do something locally we do that.

In my opinion, it's better to have a CASE statement with the month number and the number of days in that month.

It's extremely easy to determine the LEAP YEAR and see if FEB has 28 or 29 days.

Calling a series of date functions with a neat little trick of add a month, subtract a day works - but the overhead is too much for me to handle.

[Mc Brain]

Calling a series of date functions with a neat little trick of add a month, subtract a day works - but the overhead is too much for me to handle.

Can you expand your idea?

[szlamany]

Can you expand your idea?

An array like this:

            Months(1) = 31
            Months(2) = 29
            Months(3) = 31
            Months(4) = 30
            Months(5) = 31
            Months(6) = 30
            Months(7) = 31
            Months(8) = 31
            Months(9) = 30
            Months(10) = 31
            Months(11) = 30
            Months(12) = 31

...later on in code, we take the value of the MONTH characters in the date string...

            If month < 1 Or month > 12 Then
                errorFlag = "This is not a valid month (enter dates as MMDDYYYY)"
                Exit Function
            End If
            If month = 2 Then
                If year / 100 = year \ 100 Then ' we have century
                   If year / 400 = year \ 400 Then ' and a leap year
                       MCO = 0
                   Else
                       MCO = 1
                   End If
                Else
                   If year / 4 = year \ 4 Then ' not on century and we have a leap year
                       MCO = 0
                   Else
                       MCO = 1
                   End If
                End If
            Else
                MCO = 0
            End If

            If day < 1 Or day > Months(month) - MCO Then
                errorFlag = "This is not a valid day (enter dates as MMDDYYYY)"
                Exit Function
            End If

The reason we do all this is that this is buried deep in a "general data validation" routine in our app's. We allow users to enter without SLASHES (actually prefer it) and then put the slashes in for visual aid after validation.

This was a lot of cut/paste from an old source code on my home PC - hopefully it's clean!

[edit] This might look like a lot of code, but in reality it's just a couple of IF statements and compiles into very fast machine code - much different then calling DATE functions that probably call API's

[Mc Brain]

An array like this:

            Months(1) = 31
            Months(2) = 29
            Months(3) = 31
            Months(4) = 30
            Months(5) = 31
            Months(6) = 30
            Months(7) = 31
            Months(8) = 31
            Months(9) = 30
            Months(10) = 31
            Months(11) = 30
            Months(12) = 31

...later on in code, we take the value of the MONTH characters in the date string...

            If month < 1 Or month > 12 Then
                errorFlag = "This is not a valid month (enter dates as MMDDYYYY)"
                Exit Function
            End If
            If month = 2 Then
                If year / 100 = year \ 100 Then ' we have century
                   If year / 400 = year \ 400 Then ' and a leap year
                       MCO = 0
                   Else
                       MCO = 1
                   End If
                Else
                   If year / 4 = year \ 4 Then ' not on century and we have a leap year
                       MCO = 0
                   Else
                       MCO = 1
                   End If
                End If
            Else
                MCO = 0
            End If

            If day < 1 Or day > Months(month) - MCO Then
                errorFlag = "This is not a valid day (enter dates as MMDDYYYY)"
                Exit Function
            End If

The reason we do all this is that this is buried deep in a "general data validation" routine in our app's. We allow users to enter without SLASHES (actually prefer it) and then put the slashes in for visual aid after validation.

This was a lot of cut/paste from an old source code on my home PC - hopefully it's clean!

[edit] This might look like a lot of code, but in reality it's just a couple of IF statements and compiles into very fast machine code - much different then calling DATE functions that probably call API's

I had understood your idea... but I still don't understand the statement

"Calling a series of date functions with a neat little trick of add a month, subtract a day works - but the overhead is too much for me to handle"

Besides, why do you do year / 400 = year \ 400 instead of (year MOD 400) = 0? Is it also an overhead issue?

[szlamany]

I had understood your idea... but I still don't understand the statement

Quote:
"Calling a series of date functions with a neat little trick of add a month, subtract a day works - but the overhead is too much for me to handle"

Besides, why do you do year / 400 = year \ 400 instead of (year MOD 400) = 0? Is it also an overhead issue?

I did not write that logic - someone on my staff did - so I cannot answer the MOD question.

As for the general overhead feeling. If I had some time today I would benchmark the two and see what the difference is - my feeling is that the calls to DATE functions would be much, much slower than the couple of IF statements and DIVISION logic show in my post.

I always consider how things will compile into machine instructions. Those IF and DIVISION statements in VB compile down into a dozen, if that, COMPARE, DIVIDE and JUMP operations. And it's all in-line with the VB code it's sitting in.

Calling an OUTSIDE function probably has a dozen instructions just to prepare for the call. Passing arguments - framing the stack so the DATE function can run - handling results in temporary space (since the DATE logic has functions within functions).

This matters to us because we use these standard routines of our to potentially process thousands and thousands of data elements - for report generation, filling grids, maybe importing from text files.

All this is buried in a CHANGEDATATYPE function - which is responsible for validation and transformation from "stored" to "input" to "display" formats for all our different datatypes.

[Mc Brain]

Ok, if do your tests keep me posted. I would like to know the results.

[Mc Brain]

Two more things:

If year / 100 = year \ 100 Then ' we have century
                   If year / 400 = year \ 400 Then ' and a leap year
                       MCO = 0
                   Else
                       MCO = 1
                   End If
                Else
                   If year / 4 = year \ 4 Then ' not on century and we have a leap year
                       MCO = 0
                   Else
                       MCO = 1
                   End If
                End If

First, what does MCO stand for?
Second, I think it could be...

If year / 400 = year \ 400 Then ' and a leap year
'can be divided by 100 and 4
                       MCO = 0
                   Else
'cannot be divided by 100 or 4
                      If year / 4 = year \ 4 Then ' not on century and we have a leap year
                          MCO = 0
                     Else
                         MCO = 1
                     End If
                   End If

However... I've not tested this.

[szlamany]

Centuries have to be divisible by 400 - right? So 1900 is not a leap year (it does divide by 4 though) - 2000 is a leap year.

If not a century, then if it divides by 4 - right?

I'm sure MCO stands for something like MONTH-CHECK-OFFSET - but like I said, I did not write that code...

[dglienna]

I'd like to see the speed comparison, but as I have said before, I prefer easy to read over code that is cryptic, but saves a few cycles. VB isn't known for it's speed anyways. You can speed it up somewhat, and that's what you are doing.

[Simply Me]

Ok, if do your tests keep me posted. I would like to know the results.

This is interesting. Keep me posted too. I'd like to know how to enter dates without SLASHES.

The reason we do all this is that this is buried deep in a "general data validation" routine in our app's. We allow users to enter without SLASHES (actually prefer it) and then put the slashes in for visual aid after validation.

[szlamany]

Ok - I used a link from MartinLiss about timing items - here's the code I used.

Option Explicit
Private Declare Function GetTickCount Lib "kernel32" () As Long

Private Sub Form_Load()

    ' Place this code in any Sub or Function
    Dim lngStart As Long
    Dim lngFinish As Long
    Dim lngCounterOne As Long
    Dim lngCounterTwo As Long
    Dim lngMonthCount As Long
    Dim Months(1 To 12) As Long
    Dim lngMonth As Long
    Dim lngYear As Long
    Dim mco As Long
    
    'Dim ld As Date
    Dim CheckDate1 As Date
    Dim CheckDate2 As Date
    
    Dim strDate1 As String
    Dim strDate2 As String
    
    CheckDate1 = "2004-01-15"
    CheckDate2 = "2004-02-15"
    
    ' Record the start "time"
    lngStart = GetTickCount()
    
    ' Some process that you want to time
    For lngCounterOne = 1 To 100000
        For lngCounterTwo = 1 To 5
            lngMonthCount = Day(DateSerial(Year(CheckDate1), Month(CheckDate1) + 1, 0))
            lngMonthCount = Day(DateSerial(Year(CheckDate2), Month(CheckDate2) + 1, 0))
        Next lngCounterTwo
    Next lngCounterOne
    
    ' Record the finish "time"
    
    lngFinish = GetTickCount()
    
    ' Display the difference
    
    Debug.Print "Time to complete DATE method = "; lngFinish - lngStart

    Months(1) = 31
    Months(2) = 29
    Months(3) = 31
    Months(4) = 30
    Months(5) = 31
    Months(6) = 30
    Months(7) = 31
    Months(8) = 31
    Months(9) = 30
    Months(10) = 31
    Months(11) = 30
    Months(12) = 31

    strDate1 = "01152004"
    strDate2 = "02152004"
    
    ' Record the start "time"
    lngStart = GetTickCount()
    
    ' Some process that you want to time
    For lngCounterOne = 1 To 100000
        For lngCounterTwo = 1 To 5
            lngMonth = CLng(Mid$(strDate1, 1, 2))
            lngYear = CLng(Right$(strDate1, 4))
            If lngMonth = 2 Then
                If lngYear / 100 = lngYear \ 100 Then ' we have century
                   If lngYear / 400 = lngYear \ 400 Then ' and a leap lngYear
                       mco = 0
                   Else
                       mco = 1
                   End If
                Else
                   If lngYear / 4 = lngYear \ 4 Then ' not on century and we have a leap lngYear
                       mco = 0
                   Else
                       mco = 1
                   End If
                End If
            Else
                mco = 0
            End If
            lngMonthCount = Months(lngMonth) - mco
            lngMonth = CLng(Mid$(strDate2, 1, 2))
            lngYear = CLng(Right$(strDate2, 4))
            If lngMonth = 2 Then
                If lngYear / 100 = lngYear \ 100 Then ' we have century
                   If lngYear / 400 = lngYear \ 400 Then ' and a leap lngYear
                       mco = 0
                   Else
                       mco = 1
                   End If
                Else
                   If lngYear / 4 = lngYear \ 4 Then ' not on century and we have a leap lngYear
                       mco = 0
                   Else
                       mco = 1
                   End If
                End If
            Else
                mco = 0
            End If
            lngMonthCount = Months(lngMonth) - mco
        Next lngCounterTwo
    Next lngCounterOne
    
    ' Record the finish "time"
    
    lngFinish = GetTickCount()
    
    ' Display the difference
    
    Debug.Print "Time to complete Logic/Math method = "; lngFinish - lngStart

End Sub

My goal was to compare finding the number of days in a month for two dates - a January date - which the leap year means nothing about and a Feburary date - which the leap year logic does involve.

The immediate window showed that the method I posted (logic and math without date functions) ran in nearly half the time.

Hopefully I didn't make some silly blunder in comparing these two - it's been a long day...

Time to complete DATE method =  4562 
Time to complete Logic/Math method =  2625

[dglienna]

Well, if I had the routine, I would have posted it, but I wouldn't have tried to write it to provide as an example. It would have had to be checked for errors, as I'm sure your code was. If there were half a million instances, then maybe it would worth be using, but for my use (which is none) the date method is fine.

[NotLKH]

All that is neccessary to determine days in a month???
Surely the DateSerial method is sufficient???

szalamoy, err, slaminonimiy, err, ehhh,...
salami, aren't you complicating things a bit much???

[dglienna]

its too slow, apparently.

[NotLKH]

its too slow, apparently.

Ahh. you edited...

Well, perhaps i could still ask...
Why do you say that???

[dglienna]

seems like everytime I post a quick-and-dirty method that solves the problem, it always gets improved upon, and quite often over-complicated. i've grown used to it.
it was resolved last night.

[Simply Me]

seems like everytime I post a quick-and-dirty method that solves the problem, it always gets improved upone, and quite often complicated. i've grown used to it.
it was resolved last night.

That's life we never stop learning

[szlamany]

DGlienna - look at this link and you will see some of my motivation for even making the point.

This was a very long debate about the benefits of knowing ASM...

The post and the whole thread

If every month had a fixed number of days, then I'm guessing (and that's a really tough statement to make on this forum) that the array method of storing the number of days in a month would be chosen by nearly 100% of those polled.

If that's true, then it's only because Feb has a 28 or 29 situation that makes us think up these neat, novel ways of picking the days in a month.

I use the method you posted in T-SQL all the time - it's the only way, in my opinion, to arrive at the answer.

[szlamany]

All that is neccessary to determine days in a month???
Surely the DateSerial method is sufficient???

szalamoy, err, slaminonimiy, err, ehhh,...
salami, aren't you complicating things a bit much???

No complication at all - simple straight logic to solve a problem. The problem, in this case, in my opinion, is to determine the number of days in February. The number of days in the other 11 months is a no-brainer (not a problem - not an issue - idiom use - sorry!).

[szlamany]

I'd like to see the speed comparison, but as I have said before, I prefer easy to read over code that is cryptic, but saves a few cycles. VB isn't known for it's speed anyways. You can speed it up somewhat, and that's what you are doing.

We have a strong desire in our shop to remain VB only. We have some huge algorithm and routines - report writer engines, student-class-scheduling routines - all written in VB. We have been a BASIC shop for 25+ years, because it's an easy language to maintain, support and enhance.

But since we choose to do some "extensive" and "expensive" things in BASIC, we always consider best-choice methods.

[RhinoBull]

In general, when a math function can do something locally we do that.

In my opinion, it's better to have a CASE statement with the month number and the number of days in that month.

It's extremely easy to determine the LEAP YEAR and see if FEB has 28 or 29 days.

Calling a series of date functions with a neat little trick of add a month, subtract a day works - but the overhead is too much for me to handle.

An array like this:

            Months(1) = 31
            Months(2) = 29
            Months(3) = 31
            Months(4) = 30
            Months(5) = 31
            Months(6) = 30
            Months(7) = 31
            Months(8) = 31
            Months(9) = 30
            Months(10) = 31
            Months(11) = 30
            Months(12) = 31

...later on in code, we take the value of the MONTH characters in the date string...

            If month < 1 Or month > 12 Then
                errorFlag = "This is not a valid month (enter dates as MMDDYYYY)"
                Exit Function
            End If
            If month = 2 Then
                If year / 100 = year \ 100 Then ' we have century
                   If year / 400 = year \ 400 Then ' and a leap year
                       MCO = 0
                   Else
                       MCO = 1
                   End If
                Else
                   If year / 4 = year \ 4 Then ' not on century and we have a leap year
                       MCO = 0
                   Else
                       MCO = 1
                   End If
                End If
            Else
                MCO = 0
            End If

            If day < 1 Or day > Months(month) - MCO Then
                errorFlag = "This is not a valid day (enter dates as MMDDYYYY)"
                Exit Function
            End If

The reason we do all this is that this is buried deep in a "general data validation" routine in our app's. We allow users to enter without SLASHES (actually prefer it) and then put the slashes in for visual aid after validation.

This was a lot of cut/paste from an old source code on my home PC - hopefully it's clean!

[edit] This might look like a lot of code, but in reality it's just a couple of IF statements and compiles into very fast machine code - much different then calling DATE functions that probably call API's

My head start spinning when I read all that ...
DGLIENNA provided solution using a very cute "one-liner" and what you suggested need a whole book to fit in ...
To wrap it up all I want to say is this: anyone needs days count use that "one-liner" and don't look for anything else.
If you still want to use array then don't hard code its values - create them dynamically:

Private Sub Command1_Click()
Dim i%, arDays(11) As Integer
 
    For i = 0 To 11
        arDays(i) = Day(DateSerial(Year(Now), Month(i + 1 & "/1/" & Year(Now)) + 1, 0))
        Debug.Print Format(i + 1 & "/1/" & Year(Now), "MMMM") & " - " & arDays(i) & " days"
    Next i
 
End Sub

[dglienna]

My whole point after the fourth post in the thread.

[szlamany]

My head start spinning when I read all that ...

RB - I think you might have missed my point.

A cute-one-liner is not always a perfect solution.

We happen to use DGLIENNA's one-liner in T-SQL stored procedures all the time. That's a standard practice here.

But in VB we would not do that.

If February did not have 28 or 29 days, then using that add-a-month-subtract-a-day logic would never even be considered - would it?

[RhinoBull]

I haven't missed any point ... I'm sure. But do you follow yourself?

We happen to use DGLIENNA's one-liner in T-SQL stored procedures all the time. That's a standard practice here.

But in VB we would not do that.

... no comments ...

If February did not have 28 or 29 days, ...

that's the whole point of it ...

Why in a world do you need all those million lines of code when "one-liner" does a pretty good job ? Can you explain that? Maybe in your shop it's a "good practice" - not in my ...

Regards.

[szlamany]

Why in a world do you need all those million lines of code when "one-liner" does a pretty good job ? Can you explain that? Maybe in your shop it's a "good practice" - not in my ...

Regards.

Because in VB that's not a million lines of code. Actually it's very few lines of code.

In VB the method I showed was less "lines-of-machine-code" than was the one-liner with date calls that was actually slower and more lines of machine code.

That is an issue for us.

Calling a language function - actually several - should be challenged.

That is the point.

If you saw that point already, then we simply disagree.

[szlamany]

I haven't missed any point ... I'm sure. But do you follow yourself?

Quote:
We happen to use DGLIENNA's one-liner in T-SQL stored procedures all the time. That's a standard practice here.

But in VB we would not do that.


... no comments ...

The difference is that we know the output of VB code and the executable logic that follows.

In T-SQL we are simply guessing - we could develop a USER-DEFINED function in T-SQL to do the same divide by 400/100/4 and see if Feb has 28 or 29 days - but we simply do not have the experience to know that would be faster.

[Mc Brain]

The problem is that I think you're mixing concepts. VB is known as a HIGH LEVEL programming language. If I were worried about the speed, lenght of the executable file or how it manages its memory... I would not go with a HIGH LEVEL programming language. The idea of using a HIGH LEVEL programming language is to easy the reading and coding for the programmer. It's the computer's job to do all the interpretations needed to "downsize" to a level "she" understands.

In other words, if I really needed speed I would code it in C or just Assembler. I don't think a load of Ifs "could" be substantiated just to make it a little faster. Processors, nowadays, are really fast and getting faster by month.

So, I don't think a one-liner code should be replaced (as in this example or any other similar) with a 20-line code. It's faster... I agree. It's smaller... I agree. But... who cares?? I know I don't.

[RhinoBull]

... If you saw that point already, then we simply disagree.

... and very strongly I'm afraid.
Get out of the sixties - the sooner the better.
64 bit processors are out there available, 64 bit OS is on the way and you are talking about 1/100 of a millisecond or something. Wake up. Common ...

[szlamany]

The problem is that I think you're mixing concepts. VB is known as a HIGH LEVEL programming language. If I were worried about the speed, lenght of the executable file or how it manages its memory... I would not go with a HIGH LEVEL programming language. The idea of using a HIGH LEVEL programming language is to easy the reading and coding for the programmer. It's the computer's job to do all the interpretations needed to "downsize" to a level "she" understands.

In other words, if I really needed speed I would code it in C or just Assembler. I don't think a load of Ifs "could" be substantiated just to make it a little faster. Processors, nowadays, are really fast and getting faster by month.

So, I don't think a one-liner code should be replaced (as in this example or any other similar) with a 20-line code. It's faster... I agree. It's smaller... I agree. But... who cares?? I know I don't.

Using the date functions to arrive at the answer is probably more "black-box" appropriate. No one needs to know what goes on inside the function.

Personally, I don't see those IF statements as confusing or daunting - actually I see them as a very-very simple approach to determine if Feb has 28 or 29 days.

I think it could be argued that the DATE/YEAR/MONTH logic was more confusing - and harder to modify in the future if something needed to be changed.

But at this point - I really don't want to debate this issue any further

[Mc Brain]

Personally, I don't see those IF statements as confusing or daunting - actually I see them as a very-very simple approach to determine if Feb has 28 or 29 days.

Nobody said it was confusing... just not practical.