Insert Local Date, Get UTC

[iambudi]

I have a table field with data type TIMESTAMP.
Inserting data with 'CURRENT_TIMESTAMP' will store date in local time, but when using golang time.Now() will store it in UTC.

time.Now() or time.Now().Local() return something like 2020-04-20 18:34:53.566207 +0700 WIB, in HANADB it is 2020-04-20 11:34:53.

Is there a way to make HanaDB store it as golang local time rather than UTC?

Thanks.

[stfnmllr]

The go-hdb driver does use a normalized (UTC) date / time by intention.

Just imagine that your application is used to read and write data in different time zones. Without additional information from which time zone the timestamp was created the information is unusable.

With UTC timestamps are stored time zone independently and the local date / time can be ‘calculated’ after reading from database.

Hope that helps

[iambudi]

With UTC timestamps are stored time zone independently and the local date / time can be ‘calculated’ after reading from database.

This should become developer decision to store in UTC or Local time rather than forced by sql driver. Anyone can have different case.

I guess that's why HANADB itself provide two function CURRENT_TIMESTAMP and CURRENT_UTCTIMESTAMP.

Thanks.

[stfnmllr]

This should become developer decision to store in UTC or Local time rather than forced by sql Driver

[stfnmllr]

This should become developer decision to store in UTC or Local time rather than forced by sql Driver
Which is unfortunately not possible using https://golang.org/pkg/time/#Time as canonical go representation of db date / time fields

type Time struct {
	// ...
	wall uint64
	ext  int64
	// loc specifies the Location that should be used to
	// determine the minute, hour, month, day, and year
	// that correspond to this Time.
	// The nil location means UTC.
	// All UTC times are represented with loc==nil, never loc==&utcLoc.
	loc *Location
}

Like you can see, location information is part of time.Time. The driver could whether

1. ignore location information (which is wrong)
2. or transform time to local time (which leads to information loss, as the location is not stored in db)
3. or using a normalized form like UTC to store data / time in db