uefi: fs: Add file times plumbing #138918

Ayush1325 · 2025-03-25T03:03:32Z

Add plumbing to allow conversions to and from UEFI Time to Rust SystemTime.
Also add FileTimes implementation.

petrochenkov · 2025-03-25T15:12:53Z

(I'll initially mark these PRs as waiting on author in the sense that, that they are waiting for the author to summon @nicholasbishop and get a review. It can be marked as ready when there's a review.)
@rustbot author

library/std/src/sys/pal/uefi/time.rs

Ayush1325 · 2025-04-11T19:55:36Z

@rustbot label +O-UEFI

joboet

I'm a bit worried about the edge cases here. It's not that uncommon to end up with a system time of 1970-1-1 if the devices clock is uninitialised. If the current timezone is positive, this might lead to a panic when converting it to a UNIX time. Considering the insanely large bounds afforded by secs being 64-bit, using a signed integer in the conversion algorithm would allow converting dates before the UNIX epoch as well.

Aside from that, the checked methods on SystemTime operate on the assumption that the operation will fail if the time is not representable in the operating system format – but this is currently not the case: UEFI allows times from the year 1900 up to and including the year 9999, whereas a Duration since the UNIX epoch allows representing times from 1970 up to the heat death of the universe, but not before that. I think it would be better to use the UEFI time representation for SystemTime and only convert it into a Duration for the addition/subtraction operations.

joboet · 2025-04-13T14:03:11Z

library/std/src/sys/pal/uefi/time.rs

+        let secs = if timezone == r_efi::efi::UNSPECIFIED_TIMEZONE {
+            dur.as_secs()
+        } else {
+            dur.as_secs().checked_add_signed(-timezone as i64).unwrap()


I'd use subtraction here, just like the formula in the UEFI spec.

Suggested change

dur.as_secs().checked_add_signed(-timezone as i64).unwrap()

dur.as_secs().checked_sub_signed(timezone as i64).expect("times should be representable as local UEFI times")

checked_sub_signed is currently unstable. I can add the feature if that is fine though.

joboet · 2025-04-13T14:03:49Z

library/std/src/sys/pal/uefi/time.rs

+        let remaining_secs = secs % SECS_IN_DAY;
+        let z = days + 719468;
+        let era = z / 146097;
+        let doe = z - (era * 146097);


This is clear by operator precedence, and the source doesn't use parenthesis here either.

Suggested change

let doe = z - (era * 146097);

let doe = z - era * 146097;

Ayush1325 · 2025-04-13T14:31:39Z

I'm a bit worried about the edge cases here. It's not that uncommon to end up with a system time of 1970-1-1 if the devices clock is uninitialised. If the current timezone is positive, this might lead to a panic when converting it to a UNIX time. Considering the insanely large bounds afforded by secs being 64-bit, using a signed integer in the conversion algorithm would allow converting dates before the UNIX epoch as well.

Aside from that, the checked methods on SystemTime operate on the assumption that the operation will fail if the time is not representable in the operating system format – but this is currently not the case: UEFI allows times from the year 1900 up to and including the year 9999, whereas a Duration since the UNIX epoch allows representing times from 1970 up to the heat death of the universe, but not before that. I think it would be better to use the UEFI time representation for SystemTime and only convert it into a Duration for the addition/subtraction operations.

Yes, I did come to the same conclusion. I think the reason I initially went with duration was to have a simple implementation for all the function implemented on SystemTime (since all the results there are in Duration). I will try representing SystemTime using UEFI Time internally and see how it looks.

bors · 2025-08-12T16:39:00Z

☔ The latest upstream changes (presumably #145300) made this pull request unmergeable. Please resolve the merge conflicts.

Ayush1325 · 2025-08-12T18:25:33Z

@rustbot ready

ping @nicholasbishop @joboet

petrochenkov · 2025-08-12T18:29:37Z

r? @joboet

nicholasbishop · 2025-08-12T18:36:00Z

library/std/src/sys/fs/uefi.rs


-#[derive(Copy, Clone, Debug, Default)]
-pub struct FileTimes {}
+#[derive(Copy, Clone, Debug)]


Time implements Default, so can't we keep deriving Default here and remove ZERO_TIME?

joboet · 2025-08-13T14:44:21Z

library/std/src/sys/fs/uefi.rs

-    pub fn set_modified(&mut self, _t: SystemTime) {}
+    pub fn set_accessed(&mut self, t: SystemTime) {
+        self.accessed =
+            t.to_uefi(self.accessed.timezone, self.accessed.daylight).expect("Invalid Time");


Can we avoid this panic? As the SystemTime was created successfully (i.e. checked_add did not return an error), this panic will come as a surprise to users.

A better way perhaps would be to try the initial timezone first, and if that fails, return the closest timezone (minute offset) that still allows the time to be represented. If filesystems ignore the timezone field, this would lead to the first and last 1440 minutes being collapsed into one minute, which doesn't seem too bad.

I have added the appropriate helpers to use the closest timezone. I have also added the tests that I have used locally to check the new timezone.

nicholasbishop

uefi lgtm

View changes since this review

nicholasbishop · 2025-08-26T16:29:54Z

library/std/src/sys/pal/uefi/time.rs

        system_time_internal::to_uefi(&self.0, timezone, daylight)
    }

+    /// Create UEFI Time with the closes timezone (minute offset) that still allows the time to be


Suggested change

/// Create UEFI Time with the closes timezone (minute offset) that still allows the time to be

/// Create UEFI Time with the closest timezone (minute offset) that still allows the time to be

beetrees

Thanks for working on this.

View changes since this review

beetrees · 2025-08-26T21:35:27Z

library/std/src/sys/fs/uefi.rs

 pub struct FileAttr {
    attr: u64,
    size: u64,
+    created: r_efi::efi::Time,


UEFI allows creation time to be set, so created should be part of the FileTimes struct (a future PR can then use it to implement set_created in an extension trait like on Windows and Apple platforms).

beetrees · 2025-08-26T21:51:23Z

library/std/src/sys/fs/uefi.rs

-    pub fn set_accessed(&mut self, _t: SystemTime) {}
-    pub fn set_modified(&mut self, _t: SystemTime) {}
+    pub fn set_accessed(&mut self, t: SystemTime) {
+        self.accessed = t.to_uefi_loose(self.accessed.timezone, self.accessed.daylight);


.timezone and .daylight will always be zero here (unless set_accessed/set_modified was called previously and that time had to have it's timezone adjusted to fit in the range of EFI_TIME). The EDK II FAT driver will ignore the timezone when setting the time.. As FAT stores timestamps in the system local time, this conversion should use the current system timezone from the runtime services GetTime in order to be compatible with that driver's behaviour. This conversion should be done in the File::set_times implementation to have consistent behaviour in the (unlikely) event the timezone is changed between the call to set_accessed and the actual setting of the file times in File::set_times (which I believe isn't being implemented in this PR); therefore the FileTimes struct should look something like struct FileTimes { accessed: SystemTime, modified: SystemTime, created: SystemTime }.

I have converted all FileTimes members to be SystemTime.

beetrees · 2025-08-26T21:51:27Z

library/std/src/sys/fs/uefi.rs


    pub fn modified(&self) -> io::Result<SystemTime> {
-        unsupported()
+        Ok(SystemTime::from_uefi(self.times.modified))


FAT timestamps are always stored in local time in the system timezone, and the EDK II FAT driver uses EFI_UNSPECIFIED_TIMEZONE to represent this. Therefore, if the modified/accessed/created EFI time has a timezone of unspecified, this conversion should use the timezone from the runtime services GetTime in order to be compatible.

Since this PR does not have any boundary code, I have added helper uefi_to_systemtime that uses the timezone from current time in unspecified timezone cases.
When converting back to UEFI time, I am also using local timezone now in the helper systemtime_to_uefi

All these helpers are local fs since we do not know if some other subsystem might want to handle these specific cases differently.

joboet · 2025-08-29T17:20:16Z

library/std/src/sys/pal/uefi/time.rs


        // FIXME(#126043): use checked_sub_signed once stabilized
        let secs =
            dur.as_secs().checked_add_signed((-timezone as i64) * SECS_IN_MINUTE as i64).unwrap();


This is the wrong sign – you need to add the new timezone offset. Also, this will panic for positive timezones when the duration is very small – the overflow check should occur below.

The UEFI fields are in locatime. And it is given in the spec that LocalTime = UTC - Timezone. When converting from UEFI to our time in secs from epoch, we do LocalTime + Timezone since we want to have the secs when time is in UTC.
So to get back localtime, wouldn't we do UTC secs - Timezone?

Ah, I got confused because RFC 3339 uses the exact opposite sign convention. You are indeed correct.

This will still panic for Duration::ZERO in e.g. timezone 1440 though.

joboet · 2025-08-29T17:33:13Z

library/std/src/sys/pal/uefi/time.rs

-    const SECS_IN_MINUTE: u64 = 60;
    const SECS_IN_HOUR: u64 = SECS_IN_MINUTE * 60;
    const SECS_IN_DAY: u64 = SECS_IN_HOUR * 24;
    const TIMEZONE_DELTA: u64 = 1440 * SECS_IN_MINUTE;


Maybe you could rename this to SYSTEMTIME_TIMEZONE so that its clearer in which direction the delta applies?

joboet · 2025-08-29T17:36:23Z

library/std/src/sys/pal/uefi/time.rs


        // Convert to seconds since 1900-01-01-00:00:00 in timezone.
-        let Some(secs) = secs.checked_sub(TIMEZONE_DELTA) else { return None };
+        let Some(secs) = secs.checked_sub(TIMEZONE_DELTA) else {


Suggested change

let Some(secs) = secs.checked_sub(TIMEZONE_DELTA) else {

let Some(secs) = secs.checked_add_signed((timezone - SYSTEMTIME_TIMEZONE) as i64 * SECS_IN_MINUTE) else {

This should also not be needed now. The first subtraction contains the comment explaining why it is fine to unwrap, since it can never fail.

library/std/src/sys/pal/uefi/time.rs

joboet · 2025-08-29T18:31:04Z

library/std/src/sys/pal/uefi/time.rs

+        let Some(secs) = secs.checked_sub(TIMEZONE_DELTA) else {
+            let new_tz =
+                (secs / SECS_IN_MINUTE - if secs % SECS_IN_MINUTE == 0 { 0 } else { 1 }) as i16;
+            return Err(new_tz);


Is there a usecase for to_uefi outside of to_uefi_loose? Otherwise you could update the timezone here instead of returning an error.

Well, I am not sure how to deal with the other case (end of re-presentable time) early. So not sure if there is much benefit if I need to do a recursive call at the end.

I can think about optimizing it more over the weekend if that is required. But it is possible that having this strict version of the function will be required when adding something in the future anyway.

beetrees · 2025-09-01T00:23:50Z

library/std/src/sys/fs/uefi.rs

+    /// Convert to UEFI Time with the current timezone.
+    #[allow(dead_code)]
+    fn systemtime_to_uefi(time: SystemTime) -> r_efi::efi::Time {
+        time.to_uefi_loose(current_timezone(), 0)


This should also take the daylight value from time::system_time_internal::now().

beetrees · 2025-09-01T00:30:24Z

library/std/src/sys/fs/uefi.rs

+    accessed: SystemTime,
+    modified: SystemTime,
+    created: SystemTime,


Suggested change

accessed: SystemTime,

modified: SystemTime,

created: SystemTime,

accessed: Option<SystemTime>,

modified: Option<SystemTime>,

created: Option<SystemTime>,

Apologies, my suggestion in my previous review comment was incomplete. These all need to be optional as when using FileTimes to set file timestamps it's possible to only set some of the timestamps.

beetrees · 2025-09-01T00:40:38Z

library/std/src/sys/fs/uefi.rs

+
+    /// EDK2 FAT driver uses EFI_UNSPECIFIED_TIMEZONE to represent localtime. So for proper
+    /// conversion to SystemTime, we use the current time to get the timezone in such cases.
+    #[allow(dead_code)]


Suggested change

#[allow(dead_code)]

#[expect(dead_code)]

To ensure the attribute gets removed once the function is used (same with the #[allow(dead_code)] on systemtime_to_uefi).

phip1611

LGTM.

PS: Still not familiar with the development model and best practices within Rust std itself.

View changes since this review

phip1611 · 2025-09-11T06:18:26Z

library/std/src/sys/fs/uefi.rs

        FileType::from_attr(self.attr)
    }

    pub fn modified(&self) -> io::Result<SystemTime> {


is returning a Result here enforced by higher-level APIs in Rust STD? If not, why not return Option<SystemTime>?

Yup, it is.

phip1611 · 2025-09-11T06:18:51Z

library/std/src/sys/fs/uefi.rs

+
+    /// EDK2 FAT driver uses EFI_UNSPECIFIED_TIMEZONE to represent localtime. So for proper
+    /// conversion to SystemTime, we use the current time to get the timezone in such cases.
+    #[expect(dead_code)]


why dead code?

Well, just to keep the PRs small to review, and maintain continuity in future PRs. Any interactions with these conversions will require implementing GetInfo, which uses a C DST (and hence would require care and proper review) and thus needs to be a separate PR.

Also, the to and fro conversion are strongly related. So best to present them in the same PR.

It might be 2026 by the time that I start upstreaming code that requires conversion from UEFI to systemtime. So I would probably forget a lot of the important information in the current discussion. Having a conversion function already present saves having to repeat the same discussion (or worse, letting wrong code be merged).

- Add FileTimes implementation. Signed-off-by: Ayush Singh <[email protected]>

rustbot · 2025-09-26T15:23:31Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

joboet · 2025-09-26T15:41:29Z

library/std/src/sys/fs/uefi.rs

 pub struct FileAttr {
    attr: u64,
    size: u64,
+    times: FileTimes,


If I understand correctly, UEFI's EFI_FILE_INFO always contains the file times, right? Then this shouldn't be FileTimes, but rather unconditionally contain the SystemTimes. That also gets rid of the weird unsupported error in the accessors below.

joboet · 2025-09-30T15:58:42Z

library/std/src/sys/pal/uefi/tests.rs

    assert_eq!(from_uefi(&t), Duration::new(1440 * SECS_IN_MINUTE, 0));
    assert_eq!(t, to_uefi(&from_uefi(&t), 0, 0).unwrap());
-    assert!(to_uefi(&from_uefi(&t), -1440, 0).is_some());
+    assert!(to_uefi(&from_uefi(&t), -1440, 0).is_err());


Something is wrong in the code, this should succeed (localtime = UTC - timezone, so the local time is after the 1st of january 1900).

joboet · 2025-09-30T16:01:01Z

library/std/src/sys/pal/uefi/tests.rs

+
+    let inp = Duration::from_secs(1450 * SECS_IN_MINUTE + 10);
+    let new_tz = to_uefi(&inp, 1440, 0).err().unwrap();
+    assert_eq!(new_tz, 9);


This is incorrect, if 1450 * SECS_IN_MINUTE is representable in timezone 10, then times after that should be too, right?

joboet · 2025-09-30T16:03:02Z

library/std/src/sys/pal/uefi/time.rs

    const SECS_IN_HOUR: u64 = SECS_IN_MINUTE * 60;
    const SECS_IN_DAY: u64 = SECS_IN_HOUR * 24;
-    const TIMEZONE_DELTA: u64 = 1440 * SECS_IN_MINUTE;
+    const SYSTEMTIME_TIMEZONE: u64 = 1440 * SECS_IN_MINUTE;


The timezone for SystemTime is -1440, since that is the timezone with the earliest representable value. So the sign of this value should be flipped (as well as the sign of the additions/subtractions you use it for).

joboet · 2025-09-30T16:05:16Z

library/std/src/sys/pal/uefi/time.rs

+        let adjusted_localtime_epoc: u64 = localtime_epoch + SYSTEMTIME_TIMEZONE;

        let epoch: u64 = if t.timezone == r_efi::efi::UNSPECIFIED_TIMEZONE {
            adjusted_localtime_epoc
        } else {
            adjusted_localtime_epoc
                .checked_add_signed((t.timezone as i64) * SECS_IN_MINUTE as i64)
                .unwrap()
        };


Splitting this calculation is confusing to me, as we want to do a conversion from the original timezone to timezone -1440. Could you perhaps normalise the timezone first (change UNSPECIFIED_TIMEZONE to UTC) and then do the conversion in one go?

joboet · 2025-09-30T16:07:35Z

library/std/src/sys/pal/uefi/time.rs


        // FIXME(#126043): use checked_sub_signed once stabilized
        let secs =
            dur.as_secs().checked_add_signed((-timezone as i64) * SECS_IN_MINUTE as i64).unwrap();


This will still panic for Duration::ZERO in e.g. timezone 1440 though.

bors · 2025-10-22T16:49:10Z

☔ The latest upstream changes (presumably #147826) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot assigned petrochenkov Mar 25, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 25, 2025

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 25, 2025

beetrees reviewed Mar 25, 2025

View reviewed changes

library/std/src/sys/pal/uefi/time.rs Outdated Show resolved Hide resolved

Ayush1325 force-pushed the uefi-fs-time branch from 394434c to 4c497b4 Compare March 30, 2025 17:11

Ayush1325 mentioned this pull request Apr 2, 2025

Tracking Issue for uefi-std #100499

Open

rustbot added the O-UEFI UEFI label Apr 11, 2025

joboet reviewed Apr 13, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch from 4c497b4 to 48330eb Compare August 12, 2025 16:43

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 12, 2025

rustbot assigned joboet and unassigned petrochenkov Aug 12, 2025

nicholasbishop reviewed Aug 12, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch from 48330eb to e21995b Compare August 12, 2025 18:38

joboet reviewed Aug 13, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch from e21995b to 6637ec8 Compare August 13, 2025 16:49

Ayush1325 requested review from joboet and nicholasbishop August 16, 2025 06:36

nicholasbishop approved these changes Aug 26, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch from 6637ec8 to 0632fd5 Compare August 26, 2025 17:24

beetrees suggested changes Aug 26, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch from 0632fd5 to fc63980 Compare August 27, 2025 06:51

joboet requested changes Aug 29, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 29, 2025

beetrees suggested changes Sep 1, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch 3 times, most recently from 9bb2a65 to c7325fc Compare September 1, 2025 06:09

phip1611 approved these changes Sep 11, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-fs-time branch from c7325fc to 9425040 Compare September 26, 2025 12:59

This comment has been minimized.

Sign in to view

uefi: fs: Add file times plumbing

0629cda

- Add FileTimes implementation. Signed-off-by: Ayush Singh <[email protected]>

Ayush1325 force-pushed the uefi-fs-time branch from 9425040 to 0629cda Compare September 26, 2025 15:23

Ayush1325 requested a review from joboet September 26, 2025 15:24

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 26, 2025

joboet reviewed Sep 30, 2025

View reviewed changes

joboet added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 21, 2025

	dur.as_secs().checked_add_signed(-timezone as i64).unwrap()
	dur.as_secs().checked_sub_signed(timezone as i64).expect("times should be representable as local UEFI times")

	/// Create UEFI Time with the closes timezone (minute offset) that still allows the time to be
	/// Create UEFI Time with the closest timezone (minute offset) that still allows the time to be

	let Some(secs) = secs.checked_sub(TIMEZONE_DELTA) else {
	let Some(secs) = secs.checked_add_signed((timezone - SYSTEMTIME_TIMEZONE) as i64 * SECS_IN_MINUTE) else {

uefi: fs: Add file times plumbing #138918

Are you sure you want to change the base?

uefi: fs: Add file times plumbing #138918

Uh oh!

Conversation

Ayush1325 commented Mar 25, 2025

Uh oh!

petrochenkov commented Mar 25, 2025

Uh oh!

Uh oh!

Ayush1325 commented Apr 11, 2025

Uh oh!

joboet left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ayush1325 commented Apr 13, 2025

Uh oh!

bors commented Aug 12, 2025

Uh oh!

Ayush1325 commented Aug 12, 2025

Uh oh!

petrochenkov commented Aug 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nicholasbishop left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

beetrees left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nicholasbishop left a comment •

edited by rustbot

Loading

beetrees left a comment •

edited by rustbot

Loading

phip1611 left a comment •

edited by rustbot

Loading