new Time().fromJSDate() sets timezone to 'floating'

[nthgol]

I would have expected fromJSDate() to respect the timezone/offset of the JSDate supplied as an argument, however, the code defaults to Timezone.localTimezone, which is floating.

This can be pretty dangerous as local environments will behave pretty different to cloud deployments. It leads to a solution like:

const newTime = new ICAL.Time.fromJSDate(
        moment.tz(dateTime, timezone).toDate()
    ) //this timezone will by default be in local timezone/floating of server, regardless of what js date you feed into it

    //fix timezone
    newTime.timezone = timezone //not sure if necessary, but it comes with the initial parsed version of ics file
    newTime.zone = new ICAL.Timezone({
        tzid: timezone,
    })

Also - while i'm at it - what is the timezone property on a Time? its not documented but it shows up when parsing an ics.

[kewisch]

This is a tricky case, as there is no real timezone information available on the js date, just an offset. In theory we could assume one of the Etc timezones, but to get a reliable timezone I think this should be the responsibility of the client code.

[dilyanpalauzov]

I would have expected fromJSDate() to respect the timezone/offset of the JSDate supplied as an argument,

The argument contains only the seconds since unix epoch start. The argument, the JavaScript Date object, contains no timezone. What a Date object contains can be retreived by calling date.valueOf(). The Date object does not contain even an utc-offset, but it can derive it from the environment.

[kewisch]

I'm going to close this one because I believe the behavior is expected. If someone wants to add documentation around this I'm open to PRs and additions to the wiki.