Timezone location is ignored when formatting time.Time to Excel date.

[btnmasher]

Description

Using the StreamWriter (possibly with non-streaming API as well but haven't tested as much), outputting a cell with a time.Time value that has its loc field defined with a valid time.Location does not result in a timezone-accurate float value being written to Excel.

If the original time value was parsed from a UTC timestamp string, and it had its location specified by using .In(timezone) to set the loc field, it seems this is ignored by excelize's conversion to an excel float value (ie: it never applies the timezone offset).

A workaround for this for the time being:

	// Ignoring errors for demonstration
	timeStringUTC := "2009-11-10T23:00:00Z"
	timezone, _ := time.LoadLocation("America/New_York")
	date, _ := time.Parse(time.RFC3339Nano, timeStringUTC)
	_, offset := date.In(timezone).Zone() // Get the offset (in seconds) of the timestamp as if it were from the specified target timezone
	fixedDate := date.Add(time.Duration(offset) * time.Second) // Manually apply the offset
	// Use fixedDate as the value for a Cell ....

Steps to reproduce the issue:

1. Start a StreamWriter write flow.
2. Create a time.Time value and set its location:

        date := time.Parse(time.RFC3339Nano, "2009-11-10T23:00:00Z") // a UTC value
        timezone := time.LoadLocation("America/New_York")
        dateWithTz := date.In(timezone) // Set the location of the time value

3. Create a Cell{} and set it's Value field with the time value.
4. Write the Cell to a row with .SetRow()
5. Observe the time value in spreadsheet software in comparison with the specified timezone.

Describe the results you received:
Cell in spreadsheet software shows the time as UTC instead of specified timezone.

Describe the results you expected:
Cell in spreadsheet software shows the correct time for the timezone specified.

Output of go version:

go version go1.17.2 darwin/amd64

Excelize version or commit ID:

adecf44

Environment details (OS, Microsoft Excel™ version, physical, etc.):

MacOS Big Sur

[xuri]

Thanks for your issue, I have fixed it, please upgrade to the master branch code, and this patch will be released in the next version.

[dolmen]

The change is in commit 7907650.

[dolmen]

Unfortunately the change is, like the suggested workaround in the description of this issue, just incorrect because it assumes that the time zone offset is fixed. But this is not the case over time: time offset change in history, but also much more often in timezone that use daylight saving.

So the only safe timezone to use with excelize is still UTC.

[btnmasher]

Unfortunately the change is, like the suggested workaround in the description of this issue, just incorrect because it assumes that the time zone offset is fixed. But this is not the case over time: time offset change in history, but also much more often in timezone that use daylight saving.

So the only safe timezone to use with excelize is still UTC.

Can you elaborate further why this doesn't work, or perhaps demonstrate an edge case?