std: sys: pal: uefi: Overhaul Time #139806

Ayush1325 · 2025-04-14T13:49:49Z

Use UEFI time format for SystemTime.

All calculations and comparisons are being done using UnixTime since UEFI Time format does not seem good fit for those calculations.

I have tested the conversions and calculations, but I am not sure if there is a way to run unit tests for platform specific code in Rust source.

The only real benefit from using UEFI Time representation is that to and fro conversion will preserve daylight and timezone values.

r? @joboet

fbstj · 2025-04-14T14:15:32Z

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

+        }
+
+        pub(crate) const fn checked_add(&self, dur: Duration) -> Self {
+            let temp: u32 = self.usecs + dur.subsec_nanos();


you're combining something called usecs with something called nanos that doesn't seem to be correct?

EDIT: it looks like usecs should be called nanos thruout the file?

I have renamed it to nanos now. The reason for using nanos instead of normal microseconds (which is uses in unix) is because nanoseconds are stored in the UEFI Time normally.

Ayush1325 · 2025-04-16T06:41:14Z

@rustbot label +O-UEFI

joboet · 2025-04-19T17:39:36Z

This still doesn't solve the problem that checked_add and checked_sub can return Some even though the time does not fit into the bounds of the UEFI time structure. The other problem is that the unspecified timezone is not handled correctly – it's not equal to UTC and comparing/operating on a time with a specified timezone (such as the UNIX epoch) with a time with unspecified timezone is not a defined operation. A panic might be justified in that case.

Then, there is a design question: I think it might be more advantageous to convert the time and date directly into seconds (just like in the old version) as all of the operations use seconds, and it's unlikely that one would create a SystemTime without performing arithmetic on it. You'd still need to preserve the timezone information in SystemTime though, as it's necessary for bound-checking.

Ayush1325 · 2025-04-19T17:46:18Z

This still doesn't solve the problem that checked_add and checked_sub can return Some even though the time does not fit into the bounds of the UEFI time structure.

You mean they should fail for bounds outside of those defined here? Or should it fail when the values don't fit in the underlying data structure?

UINT16 Year; // 1900 - 9999
UINT8 Month; // 1 - 12
UINT8 Day; // 1 - 31
UINT8 Hour; // 0 - 23
UINT8 Minute; // 0 - 59
UINT8 Second; // 0 - 59
UINT32 Nanosecond; // 0 - 999,999,999
INT16 TimeZone; // --1440 to 1440 or 2047

The other problem is that the unspecified timezone is not handled correctly – it's not equal to UTC and comparing/operating on a time with a specified timezone (such as the UNIX epoch) with a time with unspecified timezone is not a defined operation. A panic might be justified in that case.

Ok, but should unspecified to unspecified calculation be fine? Currently the timezone on my qemu also shows up as unspecified, so I think they should be allowed.

Then, there is a design question: I think it might be more advantageous to convert the time and date directly into seconds (just like in the old version) as all of the operations use seconds, and it's unlikely that one would create a SystemTime without performing arithmetic on it. You'd still need to preserve the timezone information in SystemTime though, as it's necessary for bound-checking.

Ok, I was thinking the same as all that to and fro conversion for everything was getting a bit too much.

joboet · 2025-04-19T18:00:00Z

This still doesn't solve the problem that checked_add and checked_sub can return Some even though the time does not fit into the bounds of the UEFI time structure.

You mean they should fail for bounds outside of those defined here? Or should it fail when the values don't fit in the underlying data structure?

I think we should use the defined bounds (so years from 1900–9999, etc.). SetTime is specified to report an error if the time is outside these bounds, and I think it makes sense to respect that.

The other problem is that the unspecified timezone is not handled correctly – it's not equal to UTC and comparing/operating on a time with a specified timezone (such as the UNIX epoch) with a time with unspecified timezone is not a defined operation. A panic might be justified in that case.

Ok, but should unspecified to unspecified calculation be fine? Currently the timezone on my qemu also shows up as unspecified, so I think they should be allowed.

I agree. Only unspecified-specified calculations are undefined.

Then, there is a design question: I think it might be more advantageous to convert the time and date directly into seconds (just like in the old version) as all of the operations use seconds, and it's unlikely that one would create a SystemTime without performing arithmetic on it. You'd still need to preserve the timezone information in SystemTime though, as it's necessary for bound-checking.

Ok, I was thinking the same as all that to and fro conversion for everything was getting a bit too much.

😄 yeah... I'd maybe still choose a different timebase than UNIX time. You could e.g. use 1900-01-01-00:00,0[local] as base, which would allow you to use Duration again, since all valid times are forward from that date.

Ayush1325 · 2025-04-19T18:05:25Z

😄 yeah... I'd maybe still choose a different timebase than UNIX time. You could e.g. use 1900-01-01-00:00,0[local] as base, which would allow you to use Duration again, since all valid times are forward from that date.

So how should conversion be done? UEFI -> Unix -> Anchor to 1900-01-01-00:00,0 ?
I am not sure how to account for leap years and all that stuff without going through Unix (which has already been documented extensively)

joboet · 2025-04-19T18:11:07Z

The source for the algorithm you cite already does a conversion from a timebase of 0000-03-01 to 1970-01-01 by adding/subtracting an offset from the day count.

The first step in the computation is to shift the epoch from 1970-01-01 to 0000-03-01:
z += 719468;

We'd simply need to find the offset for 1900-01-01, use it in the algorithm instead and adjust the UNIX_EPOCH constant accordingly.

joboet · 2025-04-19T18:30:52Z

The source for the algorithm you cite already does a conversion from a timebase of 0000-03-01 to 1970-01-01 by adding/subtracting an offset from the day count.
The first step in the computation is to shift the epoch from 1970-01-01 to 0000-03-01:
z += 719468;
We'd simply need to find the offset for 1900-01-01, use it in the algorithm instead and adjust the UNIX_EPOCH constant accordingly.

By my calculation (well, by inputting the time into the algorithm), the day offset is 693901 for 1900-01-01.

Ayush1325 · 2025-04-20T16:31:12Z

The source for the algorithm you cite already does a conversion from a timebase of 0000-03-01 to 1970-01-01 by adding/subtracting an offset from the day count.
The first step in the computation is to shift the epoch from 1970-01-01 to 0000-03-01:
z += 719468;
We'd simply need to find the offset for 1900-01-01, use it in the algorithm instead and adjust the UNIX_EPOCH constant accordingly.
By my calculation (well, by inputting the time into the algorithm), the day offset is 693901 for 1900-01-01.

I have adjusted both conversion offsets and run some initial tests with time anchored to 1900-01-01. Additionally, I have added checks to ensure that the results of calculations are representable in UEFI Time.

Ayush1325 · 2025-05-03T15:55:22Z

ping @joboet

beetrees · 2025-05-03T16:16:09Z

I don't think keeping track of the timezone in SystemTime is the right solution here. In particular (AFAICT), the FAT driver in EDK II ignores the timezone (FAT doesn't specify what timezone timestamps are stored in, so Windows and Linux interpret the file times in the current system timezone), meaning that after this PR, setting a file's modification time to two "equal" SystemTimes can result in a different actual timestamp being stored if the "equal" SystemTimes have different timezones. Instead, I think a better idea would be to always convert the timestamp to UTC before storing it in SystemTime, and:

When fetching the current time, use UTC as the timezone if the timezone is unspecified. This is how EDK II handles it in RTC drivers AFAICT, so would be consistent with the rest of the ecosystem.
When fetching a file time from the filesystem, use the timezone from the current time if the filesystem file time has an unspecified timezone. This ensures FAT timestamps are interpreted correctly.
When storing a file time to the filesystem, use the timezone from the current time. This ensures FAT timestamps are correctly stored.

Ayush1325 · 2025-05-04T05:33:26Z

I don't think keeping track of the timezone in SystemTime is the right solution here. In particular (AFAICT), the FAT driver in EDK II ignores the timezone (FAT doesn't specify what timezone timestamps are stored in, so Windows and Linux interpret the file times in the current system timezone), meaning that after this PR, setting a file's modification time to two "equal" SystemTimes can result in a different actual timestamp being stored if the "equal" SystemTimes have different timezones. Instead, I think a better idea would be to always convert the timestamp to UTC before storing it in SystemTime, and:

So, the timestamp in SystemTime::dur is UTC even right now. Timezone is only used for the following:

Converting back to UEFI Time.
Comparison between SystemTime. Basically, it is fine to compare times from unspecified timezones, and it is fine to compare between specified timezones, but comparison between unspecified timezone and specified timezone is not allowed.

* When fetching the current time, use UTC as the timezone if the timezone is unspecified. This is how EDK II handles it in RTC drivers AFAICT, so would be consistent with the rest of the ecosystem.

Well, that does explain the weird behavior I was observing on OVMF. I can see that I get unspecified timezone, even though I can see the timestamp is UTC.

Why does RuntimeServices->GetTime ever return unspecified time to begin with if unspecified is to be treated the same as UTC?

* When fetching a file time from the filesystem, use the timezone from the current time if the filesystem file time has an unspecified timezone. This ensures FAT timestamps are interpreted correctly.

* When storing a file time to the filesystem, use the timezone from the current time. This ensures FAT timestamps are correctly stored.

Do you have any idea what Project Mu does? If everyone disregards the spec, I guess we might as well. But we probably still need to check.

beetrees · 2025-05-04T15:02:18Z

Why does RuntimeServices->GetTime ever return unspecified time to begin with if unspecified is to be treated the same as UTC?

Some RTCs always store the current time in UTC, and their drivers will adjust the returned time for the TimeZone if the TimeZone is not EFI_UNSPECIFIED_TIMEZONE, leading to UTC being returned when the time zone is unspecified in these cases. The unspecified time zone is used as the default time zone, so will occur when the time zone hasn't ever been set with SetTime (of course, if the time has never been set the actual time is unlikely to be correct either).

Do you have any idea what Project Mu does? If everyone disregards the spec, I guess we might as well. But we probably still need to check.

Project Mu is based on EDK II and it appears to have not changed how FAT timestamps are handled (it also seems to have the same RTC drivers more or less AFAICT).

Ayush1325 · 2025-05-11T05:13:24Z

@beetrees Sorry for the late reply. Was busy with college stuff.

I have been pondering things a bit, and I am not sure why we need to do any modification to the time we get from UEFI in Rust. Let's look at Rust's SystemTime API:

Construct a new instance

The only way to do this, is SystemTime::now. One can then use calculations on this get a desired time, but there is no way to construct this structure any other way from user API, at least for now.

So any instance used in comparison and other things will also only come from the same way of construction.

Note: If someone calls SetTime, and goes from Unspecified to UTC or vice versa, and then tries to copare to previous time, then I personally would consider it a user error.

Internal Usage

There might be use cases where we do want to interpret SystemTime Timezone differently, but I feel like that should be on a case by case basis. The base SysteTime implementation should not make any assumption regarding this.

beetrees · 2025-05-11T18:40:57Z

Construct a new instance

The only way to do this, is SystemTime::now. One can then use calculations on this get a desired time, but there is no way to construct this structure any other way from user API, at least for now.

A SystemTime can also be constructed using SystemTime::UNIX_EPOCH. This allows converting between a Unix timestamp and SystemTime. For example, the Unix timestamp of a SystemTime can be obtained by calling .duration_since(SystemTime::UNIX_EPOCH).

Ayush1325 · 2025-05-12T03:54:10Z

A SystemTime can also be constructed using SystemTime::UNIX_EPOCH. This allows converting between a Unix timestamp and SystemTime. For example, the Unix timestamp of a SystemTime can be obtained by calling .duration_since(SystemTime::UNIX_EPOCH).

Good point. I have updated the PR.

beetrees · 2025-05-16T15:14:02Z

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

+        // Check if can be represented in UEFI
+        if temp.to_uefi(0, 0).is_some() { Some(temp) } else { None }


Suggested change

// Check if can be represented in UEFI

if temp.to_uefi(0, 0).is_some() { Some(temp) } else { None }

Some(temp)

I don't think this check is necessary here. Many other platforms (e.g. many 32-bit Unix targets such as x86 FreeBSD) allow SystemTime to have a greater range than the underlying system time representation. If a SystemTime doesn't fit in the underlying system time representation, then any operations that need to convert to the underlying system representation (currently only File::set_times) will fail with an InvalidInput IO error. Additionally, what time's are representable in the UEFI time format will depend on the timezone, so this check disallow some representable times that are representable in the UEFI time format in some timezones but not UTC.

beetrees · 2025-05-16T15:17:29Z

Could you also add a test to check that the minimum and maximum possible r_efi::system::Time are converted correctly to and from SystemTime?

joboet · 2025-05-23T17:40:18Z

I discussed this extensively with @beetrees at the Rust All-Hands. We agreed that there are four design constraints that we should aim to satisfy. Two constraints are imposed by std's documentation:

SystemTime should be able to represent all time values representable by the UEFI time structure – from 1899-12-31-00:00,0[UTC] to 10000-01-02-0:00,0[UTC] (note that the range is extended by one day at each end because of the time-zone field)
The operations on SystemTime should return None if and only if the resulting time is not representable as a UEFI time structure

two are imposed by the common practice on UEFI platforms

when passing an UEFI time to a UEFI service, it should be in the UTC time-zone
we should treat the unspecified timezone as UTC – matching the UEFI specification

and one is just nice to have (especially because of things like file times)

roundtripping a SystemTime through UEFI time should be lossless

Obviously, 1. and 3. conflict with each other, as valid UEFI times do not necessarily remain valid when converting to UTC. We settled on resolving this by making the conversion to UTC best-effort: If the time value is not representable in UTC, then the remaining minutes are stored in the time-zone field. That way, we can claim to be specification-conformant (modulo the interpretation of the unspecified timezone) and can blame potential time shifts on the UEFI implementation while still ensuring that things work most of the time.

What are you're thoughts here, Ayush?

Ayush1325 · 2025-05-23T18:30:37Z

I discussed this extensively with @beetrees at the Rust All-Hands. We agreed that there are four design constraints that we should aim to satisfy. Two constraints are imposed by std's documentation:
1. `SystemTime` should be able to represent all time values representable by the UEFI time structure – from 1899-12-31-00:00,0[UTC] to 10000-01-02-0:00,0[UTC] (note that the range is extended by one day at each end because of the time-zone field)

2. The operations on `SystemTime` should return `None` if and only if the resulting time is not representable as a UEFI time structure
two are imposed by the common practice on UEFI platforms
3. when passing an UEFI time to a UEFI service, it should be in the UTC time-zone

4. we should treat the unspecified timezone as UTC – matching the UEFI specification
and one is just nice to have (especially because of things like file times)
5. roundtripping a `SystemTime` through UEFI time should be lossless
Obviously, 1. and 3. conflict with each other, as valid UEFI times do not necessarily remain valid when converting to UTC. We settled on resolving this by making the conversion to UTC best-effort: If the time value is not representable in UTC, then the remaining minutes are stored in the time-zone field. That way, we can claim to be specification-conformant (modulo the interpretation of the unspecified timezone) and can blame potential time shifts on the UEFI implementation while still ensuring that things work most of the time.

I think the modulo unspecified timezone is wrong. According to spec, timezone should be -1440 to 1440 or 2047, with 2047 being unspecified timezone. So we need to keep timezone in that range.

What are you're thoughts here, Ayush?

I am ok with it. I will try to update the PR as soon as I get time.

Ayush1325 · 2025-05-24T11:40:15Z

After some experimenting, I think it would be better to use 1900/1/1 at timezone -1440 min as the anchor since that is the earliest UEFI time according to spec.
We can then add this delta back when converting back to UEFI time. I think it allows us to represent all UEFI times and fulfils all the conditions.

beetrees · 2025-06-15T13:25:58Z

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

+/// When a Timezone is specified, the stored Duration is in UTC. If timezone is unspecified, then
+/// the timezone is assumed to be in UTC.
+///
+/// UEFI SystemTime is stored as Duration from 1900-01-01-00:00:00


This should mention the timezone that the lower bound is in.

beetrees · 2025-06-15T13:26:07Z

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

+        let temp = Self(self.0.checked_add(*other)?);
+
+        // Check if can be represented in UEFI
+        if temp.to_uefi(0, 0).is_some() { Some(temp) } else { None }


This needs to be updated to reflect the new upper bound for SystemTime (which is 9999-12-31 23:59:59.999999999 in timezone 1440). I'd suggest just having a MAX constant and checking against that.

beetrees · 2025-06-15T13:27:39Z

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

+        let temp = Self(self.0.checked_sub(*other)?);
+
+        // Check if can be represented in UEFI
+        if temp.to_uefi(0, 0).is_some() { Some(temp) } else { None }


Suggested change

let temp = Self(self.0.checked_sub(*other)?);

// Check if can be represented in UEFI

if temp.to_uefi(0, 0).is_some() { Some(temp) } else { None }

Some(Self(self.0.checked_sub(*other)?))

This check isn't needed as the minimum SystemTime is represented as 0 and Duration is unsigned.

beetrees · 2025-06-15T13:31:04Z

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

        assert!(t.month <= 12);
        assert!(t.month != 0);


Could add validity checks for the other fields of Time, not just month.

beetrees · 2025-06-15T13:31:29Z

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

+        assert!(timezone <= 1440);
+        assert!(timezone >= -1440);
+
+        let secs: u64 = if timezone == r_efi::efi::UNSPECIFIED_TIMEZONE {


timezone == r_efi::efi::UNSPECIFIED_TIMEZONE cannot be true at the moment as the assertions check timezone is between -1440 and 1440. Since it seems reasonable to have all SystemTime's we convert to Time have an actual timezone, I think it's reasonable to just remove the if timezone == r_efi::efi::UNSPECIFIED_TIMEZONE { branch.

Well, actually that assumption is probably not going to hold true. I am guessing that we will want to keep the time in the same timezone as what was being used previously by the driver (like FileIO, Networking, etc). And this timezone can be unspecified.

In that scenario, to make the assumption explicit, I'd expect us to pass the timezone back as UTC, or whatever else we've assumed the UNSPECIFIED_TIMEZONE to be; e.g. for file created/modified/accessed timestamps we'll probably want to assume that UNSPECIFIED_TIMEZONE is the same timezone as the timezone of GetTime() as that's what the EDK II FAT driver assumes.

Ok, I have removed the unspecified branch.

fbstj · 2025-06-15T15:14:17Z

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

+        assert!(t.day <= 31 && t.day != 0);
+
+        assert!(t.second < 60);
+        assert!(t.hour < 24);


missing minute check?

Use a time representation with 1900-01-01-00:00:00 at timezone -1440 min as anchor. This is the earliest time supported in UEFI. Signed-off-by: Ayush Singh <[email protected]>

beetrees · 2025-06-15T17:11:13Z

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

+        // Check timzone validity
+        assert!(timezone <= 1440 && timezone >= -1440);
+
+        // FIXME: use checked_sub_signed once stablized


Suggested change

// FIXME: use checked_sub_signed once stablized

// FIXME(#126043): use checked_sub_signed once stablized

nit: The FIXME should link to the tracking issue.

beetrees · 2025-06-15T17:11:17Z

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

+        // Convert to UTC
+        let Some(secs) = secs.checked_sub(TIMEZONE_DELTA) else { return None };


Suggested change

// Convert to UTC

let Some(secs) = secs.checked_sub(TIMEZONE_DELTA) else { return None };

// Convert to seconds since 1900-01-01-00:00:00 in timezone.

let Some(secs) = secs.checked_sub(TIMEZONE_DELTA) else { return None };

This isn't converting to UTC as the previous statement converted from UTC to local time.

Thanks for the catch.

phip1611 · 2025-06-16T06:49:54Z

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

        // Use 1 March as the start
        let (m_adj, overflow): (u32, bool) = (t.month as u32).overflowing_sub(3);
        let (carry, adjust): (u32, u32) = if overflow { (1, 12) } else { (0, 0) };
        let y_adj: u32 = (t.year as u32) + YEAR_BASE - carry;
        let month_days: u32 = (m_adj.wrapping_add(adjust) * 62719 + 769) / 2048;
        let leap_days: u32 = y_adj / 4 - y_adj / 100 + y_adj / 400;
-        let days: u32 = y_adj * 365 + leap_days + month_days + (t.day as u32 - 1) - 2472632;
+        let days: u32 = y_adj * 365 + leap_days + month_days + (t.day as u32 - 1) - 2447065;


might be worth it to add a CONST for the magic 2447065

Well, I am not sure if it's useful to do that. The current code is almost a one-to-one translation of the algorithms I have linked in the comments, and thus is easier to reason about.

Besides, the offset in this particular case is derived by collapsing multiple calculations into a single one (the one in to_uefi is more straightforward). So not sure if there is any good descriptive name. And just calling it const MAGIC is probably not any more useful/readable than current form.

phip1611 · 2025-06-16T06:50:27Z

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


        const YEAR_BASE: u32 = 4800; /* Before min year, multiple of 400. */

-        // Calculate the number of days since 1/1/1970
+        // Calculate the number of days since 1/1/1900


Why 1/1/1990? Might be worth it to add a comment?

phip1611 · 2025-06-16T06:51:15Z

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

+        let days = secs / SECS_IN_DAY;
+        let remaining_secs = secs % SECS_IN_DAY;
+
+        let z = days + 693901;


more magic constants (693901), might be worth it to add CONST values

Add tests to ensure that extream system times are still representable. Signed-off-by: Ayush Singh <[email protected]>

rustbot assigned joboet Apr 14, 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 Apr 14, 2025

fbstj reviewed Apr 14, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-systemtime branch from 52207df to f4cd07a Compare April 14, 2025 14:38

Ayush1325 mentioned this pull request Apr 14, 2025

Tracking Issue for uefi-std #100499

Open

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

Ayush1325 force-pushed the uefi-systemtime branch from f4cd07a to 451a576 Compare April 17, 2025 09:05

Ayush1325 force-pushed the uefi-systemtime branch 4 times, most recently from 36dd216 to 1e8af15 Compare April 19, 2025 20:37

Ayush1325 force-pushed the uefi-systemtime branch 2 times, most recently from 3fb7543 to 51e4cb2 Compare May 12, 2025 03:52

beetrees reviewed May 16, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-systemtime branch from 51e4cb2 to ac75938 Compare May 24, 2025 11:37

beetrees suggested changes Jun 15, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-systemtime branch from ac75938 to c15d6ca Compare June 15, 2025 14:17

This comment has been minimized.

Sign in to view

Ayush1325 force-pushed the uefi-systemtime branch from c15d6ca to 130703e Compare June 15, 2025 14:24

fbstj reviewed Jun 15, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-systemtime branch from 130703e to 46af23b Compare June 15, 2025 16:09

std: sys: pal: uefi: Overhaul Time

40d31f8

Use a time representation with 1900-01-01-00:00:00 at timezone -1440 min as anchor. This is the earliest time supported in UEFI. Signed-off-by: Ayush Singh <[email protected]>

beetrees suggested changes Jun 15, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-systemtime branch from 46af23b to b560562 Compare June 15, 2025 17:22

phip1611 reviewed Jun 16, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-systemtime branch from b560562 to 221d82d Compare June 16, 2025 09:02

std: sys: pal: uefi: tests: Add systemtime tests

9e72276

Add tests to ensure that extream system times are still representable. Signed-off-by: Ayush Singh <[email protected]>

Ayush1325 force-pushed the uefi-systemtime branch from 221d82d to 9e72276 Compare June 16, 2025 09:14

		// Check if can be represented in UEFI
		if temp.to_uefi(0, 0).is_some() { Some(temp) } else { None }

	// Check if can be represented in UEFI
	if temp.to_uefi(0, 0).is_some() { Some(temp) } else { None }
	Some(temp)

	// FIXME: use checked_sub_signed once stablized
	// FIXME(#126043): use checked_sub_signed once stablized

		// Convert to UTC
		let Some(secs) = secs.checked_sub(TIMEZONE_DELTA) else { return None };

std: sys: pal: uefi: Overhaul Time #139806

Are you sure you want to change the base?

std: sys: pal: uefi: Overhaul Time #139806

Uh oh!

Conversation

Ayush1325 commented Apr 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fbstj Apr 14, 2025 • edited 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!

Ayush1325 commented Apr 16, 2025

Uh oh!

joboet commented Apr 19, 2025

Uh oh!

Ayush1325 commented Apr 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joboet commented Apr 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ayush1325 commented Apr 19, 2025

Uh oh!

joboet commented Apr 19, 2025

Uh oh!

joboet commented Apr 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ayush1325 commented Apr 20, 2025

Uh oh!

Ayush1325 commented May 3, 2025

Uh oh!

beetrees commented May 3, 2025

Uh oh!

Ayush1325 commented May 4, 2025

Uh oh!

beetrees commented May 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ayush1325 commented May 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Construct a new instance

Internal Usage

Uh oh!

beetrees commented May 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Construct a new instance

Uh oh!

Ayush1325 commented May 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

beetrees commented May 16, 2025

Uh oh!

joboet commented May 23, 2025

Uh oh!

Ayush1325 commented May 23, 2025

Uh oh!

Ayush1325 commented May 24, 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!

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!

beetrees Jun 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Ayush1325 commented Apr 14, 2025 •

edited

Loading

fbstj Apr 14, 2025 •

edited

Loading

Ayush1325 commented Apr 19, 2025 •

edited

Loading

joboet commented Apr 19, 2025 •

edited

Loading

joboet commented Apr 19, 2025 •

edited

Loading

beetrees commented May 4, 2025 •

edited

Loading

Ayush1325 commented May 11, 2025 •

edited

Loading

beetrees commented May 11, 2025 •

edited

Loading

beetrees Jun 15, 2025 •

edited

Loading

beetrees Jun 15, 2025 •

edited

Loading

phip1611 Jun 16, 2025 •

edited

Loading