The existing record -> record signature is functional to map particular fields of a record to datetime.

{a: (date now | into int), b: blub} | into datetime a

I think we never added it because there will be a type inference challenge

Given a record input type it will be undecidable what the output type will be.

record -> record
record -> datetime

@sholderbach I would be in favor of removing this field-mapping behavior since it's simple to use update for both record -> record and table -> table conversions.

@LoicRiegel First of all, thanks for implementing this!

In previous discussions about this conversion on discord we ended up with some interesting semantics regarding missing fields.

• timezone is assumed to be local, unless provided in the record
• empty fields are filled in a specific way, the the time units bigger than the biggest provided fields are assumed to be current and smaller ones are zeroed:
• {day: 4} | date from-record has the current year and month, hour minute etc are zero
• {hour: 5} | date from-record is today 05:00
• {day: 2, minute: 4} is the 2nd day of current month, first day, 00:04
• into record | into datetime result is identical to its input

Can you implement this behavior? You can use my half-baked implementation as reference.

The existing record -> record signature is functional to map particular fields of a record to datetime.

{a: (date now | into int), b: blub} | into datetime a

Is it functional, thoug?

> {a: (date now | into int), b: blub} | into datetime a
╭───┬──────╮
│ a │ now  │
│ b │ blub │
╰───┴──────╯
> {a: (date now | into int), b: blub} | into datetime a | describe
record<a: date, b: string>

@sholderbach I would be in favor of removing this field-mapping behavior since it's simple to use update for both record -> record and table -> table conversions.

I would also be in favor of removing that, especially if it has never worked, but also this would make the signature clearer.

@LoicRiegel First of all, thanks for implementing this!

In previous discussions about this conversion on discord we ended up with some interesting semantics regarding missing fields.

• timezone is assumed to be local, unless provided in the record
• empty fields are filled in a specific way, the the time units bigger than the biggest provided fields are assumed to be current and smaller ones are zeroed:
• {day: 4} | date from-record has the current year and month, hour minute etc are zero
• {hour: 5} | date from-record is today 05:00
• {day: 2, minute: 4} is the 2nd day of current month, first day, 00:04
• into record | into datetime result is identical to its input

Can you implement this behavior? You can use my half-baked implementation as reference.

Thank you :)
Yes I can implement those extra requirements, but a few questions:

• basically that means that you take "today" and local timezone of the user as the default, but that implies that the commands will have different outputs depending on where you are and what time it is. Wouldn't you expect from a command like this to be deterministic, always produce the same output for the same input?
• Could we implement 2 strategies: (a) default everything as 0, (b) default everything using current location and date time. I could imagine something like $rec | into datetime -z LOCAL runs strategy (b) and $rec | into datetime uses strategy (a) by default, although this thing in particular is not good enough IMO
• Those assumptions should be documented somewhere: I feel like close to the code would be nice.

I'm thinking, if users want to use his/her current location and datetime, something like this would work

> date now | into record | update hour 5 | into datetime
Tue, 1 Apr 2025 05:54:54 +0200 (9 hours ago)

• basically that means that you take "today" and local timezone of the user as the default, but that implies that the commands will have different outputs depending on where you are and what time it is. Wouldn't you expect from a command like this to be deterministic, always produce the same output for the same input?

into datetime already uses the local timezone (except with unix timestamps) and fills in the larger time units with the current date.

> "5:00" | into datetime | to nuon
2025-04-01T05:00:00+03:00

It makes sense to me to have the same behavior for records.

> {hour: 5} | into datetime | to nuon
2025-04-01T05:00:00+03:00

As for deterministic behavior, because the fields smaller than the largest specified field default to 0, specifying the year and the timezone in the input makes the output deterministic.

> {year: 2025, month: 12, day: 6, hour: 16, minute: 0, second: 59, timezone: "+00:00"} | into datetime | to nuon
2025-12-06T16:00:59+00:00

• Could we implement 2 strategies: (a) default everything as 0, (b) default everything using current location and date time. I could imagine something like $rec | into datetime -z LOCAL runs strategy (b) and $rec | into datetime uses strategy (a) by default, although this thing in particular is not good enough IMO

I don't think specifying the timezone should affect the whether the current time or 0 is used. If such an option is necessary, I would rather have it as a separate flag.

• Those assumptions should be documented somewhere: I feel like close to the code would be nice.

Agreed. Adding a few more examples that demonstrate this behavior would be nice too.

into datetime already uses the local timezone (except with unix timestamps) and fills in the larger time units with the current date.

> "5:00" | into datetime | to nuon
2025-04-01T05:00:00+03:00

It makes sense to me to have the same behavior for records.

Oh I didn't realize that! In that case, I totally agree with you, we should definitely have the same behavior.

As for deterministic behavior, because the fields smaller than the largest specified field default to 0, specifying the year and the timezone in the input makes the output deterministic.

Okay fair enough

I don't think specifying the timezone should affect the whether the current time or 0 is used. If such an option is necessary, I would rather have it as a separate flag.

Yeah absolutely; forget everything I said about the possible strategies

Agreed. Adding a few more examples that demonstrate this behavior would be nice too.

Ok for a couple of examples, and maybe I'll check the documentation website.

Is it functional, thoug?

> {a: (date now | into int), b: blub} | into datetime a
╭───┬──────╮
│ a │ now  │
│ b │ blub │
╰───┴──────╯
> {a: (date now | into int), b: blub} | into datetime a | describe
record<a: date, b: string>

Your example show that it is in fact functional in that it converts the scalar values in the given columns.

I put the topic of this behavior on the meetings agenda for tomorrow. We have a ton of commands that accept optional columns (and thus operate on whole tables or records on the given columns)

The alternative for multiple columns is pretty wordy

Either multiple update $col {command} pipeline steps or the wordy invocation of update cells --columns $cols {command}

Your example show that it is in fact functional in that it converts the scalar values in the given columns.

You're right, I don't know what I what I was thinking. I guess I was visually expecting the full string describing the date, and not just "now" in the table.

I am gonna mark this as draft until we have a recommendation from the meeting.

Otherwise merging this could lead to typecheck bugs in the following situation

produces-record | into datetime $col | expects-record
produces-record | into datetime | expects-datetime

Update after I worked on it tonight

Done:

• modified the signature to add record -> any as discussed yesterday. I also left both record -> record and record -> datetime
• empty fields are filled in a specific way, the the time units bigger than the biggest provided fields are assumed to be current and smaller ones are zeroed

BTW the code grew quite a bit, I'm happy to take any improvement suggestions:)

Left to do:

• timezone is assumed to be local, unless provided in the record

Okay, I just pushed the last commits, so now we take the local timezone if the record does not contain it.

I updated the examples in the PR description

The PR is ready for review again :)

I just rebased to resolve the conflicts

Thanks for the thorough testing including the error paths and your extensive description of those in the PR note.

You're welcome! It's worth it 😄

I'll also write something down in the release notes about this one

Issue #12289, can be closed when this is merged

Also could you please close the issue?