Summary of the new feature/enhancement

I propose to add parameters to the Get-Date command that allows specifying the time difference of the value to be output.

For example:

Get-Date [-Date <DateTime | DateTimeOffset>] [-TimeZone <TimeZoneInfo>] ...

Get-Date [-Date <DateTime | DateTimeOffset>] [-Offset <TimeSpan>] ...

If these parameters are specified, the value to be output will be DateTimeOffset.

Date

Extend this parameter to accept DateTimeOffset.

TimeZone

Specify the time zone of the output.
This parameter can take the TimeZoneInfo object as well as its ID.
And it accepts UTC and Local as special values.

For example:

Get-Date -TimeZone (Get-TimeZone)

Get-Date -Date '2020-08-01T10:00:00-07:00' -TimeZone 'Asia/Tokyo'

Get-Date -TimeZone UTC

Offset

Specifies the offset of time from UTC of the value to be output.

For example:

Get-Date -Offset ([TimeSpan]::FromHours(-8))

Get-Date -Offset '-8:00'

Usecase examples

The following example shows how to convert the time expressed in the US local time to time in Japan.

Get-Date -Date '2020-08-01 10:00' -TimeZone 'America/Los_Angels' | Get-Date -TimeZone 'Asia/Tokyo' -Format f

Sunday, August 2, 2020 2:00 PM

Related proposals

#11731 suggests adding -AsLocal parameter. The -AsLocal switch is equivalent to -TimeZone Local.
The -TimeZone parameter covers the functionality of the -AsUTC, -AsLocal, and -AsKind parameters, and more widely.

I believe that using DateTimeOffset is preferable to using DateTime and DateTimeKind.

Proposed technical implementation details

Type of the -Date parameter

The -Date parameter must accept DateTime, DateTimeOffset and Int64.
Since there is no existing type that satisfies these requirements, we need to change the type of the -Date parameter to a custom type such as the following.

public readonly struct DateInput
{
    public DateInput(DateTime dateTime) {}
    
    public DateInput(DateTimeOffset dateTimeOffset) {}

    public DateInput(long tick) {}
}

Converting time zone ID to TimeZoneInfo object

TimeZoneInfo cannot be implicitly converted from a string representing its ID.
We can create a custom type for the -TimeZone parameter as described above, or create an attribute derived from the ArgentTransformationAttribute and assign it to -TimeZone parameter.

Considerations

Platform dependence of time zone ID

The TimeZoneInfo.FindSystemTimeZoneById method supports different time zone ID formats, depending on the platform.
For example, 'Pacific Standard Time' on Windows, 'America/Los_Angeles' on Linux.

We need to consider whether the parameter -TimeZone should be platform-independent and should be able to take the same value.
By using a library like TimeZoneConverter, we can make it platform-independent.

Abbreviations for time zone

For example, a format like '10:00 AM PDT' is used to describe the start time of a webinar or system maintenance.
Abbreviations for time zones such as 'PDT' are widely used, but are not specified in official specifications such as ISO 8601 and are ambiguous.
I think it would be useful if the -TimeZone parameter could accept such abbreviations, but should we support this?

Removing an -AsUTC parameter

Consider removing the -AsUTC parameter because its functionality is superseded by -TimeZone UTC.
This parameter was added in the 7.1 preview release and is not yet generally available.

Default format for DateTimeOffset

Currently, the default output for DateTimeOffset is in the following format:

DateTime      : 7/29/2020 10:31:25 PM
UtcDateTime   : 7/30/2020 5:31:25 AM
LocalDateTime : 7/29/2020 10:31:25 PM
Date          : 7/29/2020 12:00:00 AM
Day           : 29
DayOfWeek     : Wednesday
DayOfYear     : 211
Hour          : 22
Millisecond   : 54
Minute        : 31
Month         : 7
Offset        : -07:00:00
Second        : 25
Ticks         : 637316586850545851
UtcTicks      : 637316838850545851
TimeOfDay     : 22:31:25.0545851
Year          : 2020

Output in the following format, like DateTime, will be easier to read.

Wednesday, July 29, 2020 10:31:25 PM (UTC -07:00)