0

Below have a function to be overloaded requiring one parameter that can be either a DateTime or DateTimeOffset object.

What would be the appropriate method to implement this overloading? i.e

GetUtcOffset(optional Byval inDateTime as DateTime, optional Byval inDateTimeOffset as DateTimeOffset) As TimeSpan

or

GetUtcOffset(ByVal inDateTimeOrDateTimeOffset As Object) As TimeSpan

Another option maybe something similar to the Factory pattern if there's a design pattern for overloading methods or pass in something like an IArguments pattern. Tending to prefer using optional parameters over this option.

Next option is to use TwinBasic I think it provides method overloading thou until it's 100% compatibile will investigate in the future.

Second question: Which would be the prefered method If statements or a Select to test the parameter?

I have a few similar scenerios and need to consider the appropriate method.

'@Description  "Calculates the offset or difference between the time in this time zone and Coordinated Universal Time (UTC) for a particular date and time."
'Overloads
'   GetUtcOffset (DateTime)
'       Calculates the offset or difference between the time in this time zone and Coordinated
'       Universal Time (UTC) for a particular date and time.
'   GetUtcOffset (DateTimeOffset)
'       Calculates the offset or difference between the time in this time zone and Coordinated
'       Universal Time (UTC) for a particular date and time.
'Parameters
'   inObjDateTime (DateTime or DateTimeOffset)
'       The date and time to determine the offset for.
'Returns TimeSpan
'   An object that indicates the time difference between the two time zones.
'@TODO How to appropriately overload?
'   GetUtcOffset(optional Byval inDateTime as DateTime, optional Byval inDateTimeOffset as DateTimeOffset)
'or GetUtcOffset(ByVal inDateTimeOrDateTimeOffset As Object) As TimeSpan
Public Function GetUtcOffset(ByVal inDateTimeOrDateTimeOffset As Object) As TimeSpan
    If TypeOf inDateTimeOrDateTimeOffset Is DateTime Then
        'Set GetUtcOffset = GetUtcOffsetFromDateTime(inDateTimeOrDateTimeOffset)
    ElseIf TypeOf inDateTimeOrDateTimeOffset Is DateTimeOffset Then
        'Set GetUtcOffset = GetUtcOffsetFromDateTimeOffset(inDateTimeOrDateTimeOffset)
    Else
        'Raise Error invalid argument
    End If

    'Or use Select ??
    Select Case True
        Case TypeOf inDateTimeOrDateTimeOffset Is DateTime
            'Set GetUtcOffset = GetUtcOffsetFromDateTime(inDateTimeOrDateTimeOffset)
        Case TypeOf inDateTimeOrDateTimeOffset Is DateTimeOffset
            'Set GetUtcOffset = GetUtcOffsetFromDateTimeOffset(inDateTimeOrDateTimeOffset)'
        Case Else
            'Raise Error invalid argument
    End Select
End Function

For second question have examined : Select Case on an object's type in VB.NET

Any extra input would be great, I'm prefering the Select Case unless overwhelming reasons to avoid.

M. Johnstone
  • 72
  • 1
  • 6
  • 2
    VBA and VB.NET are two very different languages. In Access's code editor you have VBA, in Visual Studio you have VB.NET. Do you need a solution VBA or VB.NET? – Olivier Jacot-Descombes Jan 18 '23 at 16:27
  • I'm doing a VBA implementation of the VB.NET date time classes. This is regarding the TimeZoneInfo class for this example for doing a function overload. I've likely got similar scenerios to consider. @OlivierJacot-Descombes – M. Johnstone Jan 18 '23 at 16:34
  • 2
    If DateTime and DateTimeOffset are types then use select Case Typename(inObjDateTime) followed by Case "DateTime", Case "DateTimeOffset". Your method only needs one parameter 'InDateTimeOrDateTimeOffset' and it doesn't need to be optional. – freeflow Jan 18 '23 at 16:35
  • @freeflow I agree prefer the Case statement over If's. There were some arguments either way on the .net post and wasn't decided on which method. And prefering GetUtcOffset(ByVal inDateTimeOrDateTimeOffset As Object) As TimeSpan call to overload as requires one paramater and gets messy with the optional ones. Issue is for other cases where it's a bit more complex and maybe some sort of factory pattern might be more appropriate. If only VBA had method overloading. – M. Johnstone Jan 18 '23 at 16:43
  • 1
    I'd strongly recommend investigating the twinBasic route. There are reports of large VB6 projects being imported with few or no errors. Practically, I 'd make the assumption that because VB.Net is strongly typed you should be able to clearly identify which type of parameter is being used at each method call, and consequently it shouldn't be too hard to replace the VB.Net method with a set of specifically named methods in VBA. – freeflow Jan 18 '23 at 17:14
  • Maybe I'm missing something, but since VBA only supports `DateTime` what is the purpose of the overloading discussion? There's no `DateTimeOffset` in VBA. – Kostas K. Jan 18 '23 at 17:18
  • VBA doesn't support _overload_, neither _TimeSpan_ nor _DateTimeOffset_. You can find a full set of functions to deal with timezones and _DateTime_ in my library at **GitHub**: [VBA.Timezone-Windows](https://github.com/GustavBrock/VBA.Timezone-Windows). – Gustav Jan 18 '23 at 17:54
  • @KostasK. I'm doing a VBA implementation of the VB.net DateTime, TimeZoneInfo, TimeSpan etc classes, to handle international date times including DST. I used extensively in an old project a lot of international date time conversions. This time creating a nice library to use. :D Possible could do VBA wrappers of the .Net thou issues and atm doing the laborious way and translating the VB.net class into VBA. Same as https://github.com/kellyethridge/VBCorLib thou not VBA compatible and hasn't implemented TimeZoneInfo and using the obsolete TimeZone class. – M. Johnstone Jan 18 '23 at 18:08
  • @Gustav Had quick peek. The code looks familar to handle date times using the Win API calls. If haven't done you can also be Mac compitable. Initially don't intend to make Mac compatible thou do have old code lying around. There might be some handy code if run into any issues, generally will following the .Net source code as close as possilbe to avoid issues. Doing the "time warp" again taking a few steps back and hopefully some forward. https://www.youtube.com/watch?v=umj0gu5nEGs – M. Johnstone Jan 18 '23 at 18:30
  • @Gustav Well aware VBA sadly doesn't natively support method overloading. The post more on what appropriate design to implement it for the case mentioned. Wanted a consistent design to use to simalar cases. I think with the support of https://twinbasic.com/ it allows for method overloading which will consider using when irons out a few issues. – M. Johnstone Jan 18 '23 at 18:40
  • @freeflow Thanks. Will go with your suggestions and upvoted. Atm reluctant to use TwinBasic until 100% compatible. One issue in particular might cause headaches thou ultimately to implement backwards compatibility it appears the easiest solution, especially when dealing with LongLong types and really don't want to spend time making date time classes compatible. Only other issue anticipating is dealing with the UInt64 type might post when get around to that, atm skirting around it. – M. Johnstone Jan 18 '23 at 18:58

0 Answers0