uefi: fs: Add file times plumbing

[Ayush1325]

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

cc @nicholasbishop

r? @petrochenkov

[petrochenkov]

(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

[Ayush1325]

@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]

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")

[Ayush1325]

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

[joboet]

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]

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.