You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fwrite ignores dateTimeAs for datetime sequences #3535
If a datetime is generated by seq, fwrite writes it as an epoch timestamp, ignoring the default dateTimeAs = "ISO", likely because of an ALTREP issue. Explicitly setting dateTimeAs to "ISO" makes no difference.
From the examples above, it looks like fwrite() behaves differently depending on whether POSIXct is stored as integer vs double (e.g. sequences created by seq()), likely interacting with ALTREP and internal type checks.
My plan is to:
Reproduce the reported cases locally (including the integer/double divergence)
Trace how fwrite() detects and formats POSIXct columns internally
Check where dateTimeAs is bypassed for ALTREP or integer-backed datetime vectors
Propose a fix so dateTimeAs is respected consistently, regardless of storage mode
Before proceeding, I wanted to confirm:
Is the expected behavior that dateTimeAs should always be honored for POSIXct, independent of ALTREP or underlying storage?
Are there any known constraints or edge cases I should be careful about (e.g. performance or integer overflow)?
Happy to start with a focused PR once this approach is confirmed.
Hey Ryan. I assigned you the issue. Feel free to reach out here or in your PR, once you feel stuck. Please also make sure to carefully read our contributing guidelines.
Activity
ben-schwen commentedon Nov 7, 2025
This might be related to the storage mode of
POSIXct.Be aware to also cater for cases where integer and double representation diverge e.g.
akshhkaushik commentedon Jan 15, 2026
Hi, I’d like to work on this issue.
From the examples above, it looks like fwrite() behaves differently depending on whether POSIXct is stored as integer vs double (e.g. sequences created by seq()), likely interacting with ALTREP and internal type checks.
My plan is to:
Reproduce the reported cases locally (including the integer/double divergence)
Trace how fwrite() detects and formats POSIXct columns internally
Check where dateTimeAs is bypassed for ALTREP or integer-backed datetime vectors
Propose a fix so dateTimeAs is respected consistently, regardless of storage mode
Before proceeding, I wanted to confirm:
Is the expected behavior that dateTimeAs should always be honored for POSIXct, independent of ALTREP or underlying storage?
Are there any known constraints or edge cases I should be careful about (e.g. performance or integer overflow)?
Happy to start with a focused PR once this approach is confirmed.
ben-schwen commentedon Jan 15, 2026
Care to elaborate why you think that it is an ALTREP issue?
Besides that the approach looks fine.
rmwood0908 commentedon Mar 26, 2026
Hi, my group and I are in @igorsteinmacher OSS development class and want to work on resolving this issue!
ben-schwen commentedon Mar 26, 2026
Hey Ryan. I assigned you the issue. Feel free to reach out here or in your PR, once you feel stuck. Please also make sure to carefully read our contributing guidelines.
fwrite: fix integer-backed POSIXct writing epoch instead of ISO Rdata…