Timezone information is lost when getting DateTime from DtStart

[noftaly]

Hi,
thanks for the great library.

I've just upgraded to v3 but run into issues when extracting the date out of a dtstart generated from a RRuleSet:

const { RRuleSet } = require('rrule-rust');

// rrule with TZID
const str = `DTSTART;TZID=UTC:20260101T000000
RRULE:FREQ=MINUTELY;INTERVAL=5`;

const rrs = RRuleSet.fromString(str);

rrs.dtstart
// DtStart {
//   value: DateTime {
//     year: 2026,
//     month: 1,
//     day: 1,
//     time: { hour: 0, minute: 0, second: 0, utc: false },  <---- utc: false even though it is UTC
//     offset: undefined  <---- no offset even though tzid was set
//   },
//   tzid: 'UTC'  <---- tz defined in DtStart
// }

rrs.dtstart.value.toDate()
// Error: There is no information about time zone offset

I believe this isn't the correct behaviour, if not for all time zones it should at least recognise UTC.

Also would love a helper on dtstart to get the date without going through value (it feels unnecessary) but that's a personal preference.

Thanks!

[lsndr]

Hi! Thanks for reporting!

I believe this isn't the correct behaviour, if not for all time zones it should at least recognise UTC.

Yeah, in this scenario when DateTime is extracted after parsing, we can have time offset even not for UTC. I'll adjust this behavior.

Also would love a helper on dtstart to get the date without going through value (it feels unnecessary) but that's a personal preference.

DtStart is compound object, which consists of tzid and datetime value. This is intentional separation in order not to make users think that DateTime has some information about timezone and can actually manipulate it.

For example, in a scenario like this:

const dt = new DtStart(DateTime.local(1997, 9, 2, 9, 0, 0), 'US/Eastern')

calling something like dt.toDate() would be misleading. This library is intentionally scoped to recurrence generation only and does not provide date-time manipulation logic.

I added dateTime.toDate and dateTime.toTimestamp in order to simplify conversion of recurrent dates, received from all and between methods, to client's preferred datetime manipulation objects (temporal or luxon or whatever). Info about offset is received from rust side in such cases.

I will think about limiting usage of toDate and toTimestamp by never type for cases when there is no offset info in order to prevent unwanted runtime errors

[noftaly]

Thanks for the swift response

For example, in a scenario like this:

const dt = new DtStart(DateTime.local(1997, 9, 2, 9, 0, 0), 'US/Eastern')

calling something like dt.toDate() would be misleading.

Just so I understand, it would be misleading because you only have the tzid and not the offset so it wouldn't be safe for DSTs?
And in DateTime you have the offset because it is computed by the rust crate.

Makes sense, thanks for the clarification

I will think about limiting usage of toDate and toTimestamp by never type for cases when there is no offset info in order to prevent unwanted runtime errors

Would be great!

[lsndr]

Just so I understand, it would be misleading because you only have the tzid and not the offset so it wouldn't be safe for DSTs?

I have only tzid name. No info about offest, dsts and e.t.c.. Current means of JS do not allow you to handle different timezone (Temporal is not yet available in node)