[Solved] Time and Date
Posted: Tue Apr 17, 2012 6:18 pm
Is there any method to acquire the time and date in C without using #include <time.h>?
Inline Assembly maybe? A call to BIOS?
Inline Assembly maybe? A call to BIOS?
OSDev.org
The Place to Start for Operating System Developers
https://f.osdev.org/
[Solved] Time and Date
Page 1 of 1
Re: Time and Date
Posted: Tue Apr 17, 2012 6:32 pm
Interrupt 0x1A
Re: Time and Date
Posted: Tue Apr 17, 2012 10:11 pm
Is there a way of implementing this in inline assembly and making the value from that interrupt into a C variable.
Re: Time and Date
Posted: Tue Apr 17, 2012 10:15 pm
kammce wrote:Is there a way of implementing this in inline assembly and making the value from that interrupt into a C variable.
Sure, why wouldn't there be?
Re: Time and Date
Posted: Tue Apr 17, 2012 10:24 pm
Maybe this is what you're looking for? http://wiki.osdev.org/CMOS
Re: Time and Date
Posted: Tue Apr 17, 2012 10:34 pm
Was my point in a some what Smart @$$ way.
Plus the forum rules, Knowing how to use the C language Or Your Tool Of Choice is one of them.
Re: Time and Date
Posted: Mon Apr 23, 2012 6:52 pm
Thank you everyone.
The CMOS example was great as well. Yes, I know C (along with many other languages), but I am still in my Assembly infancy. I am not looking for an easy way, but I always believe that the forums are a great way to find information that cannot easily be pieced together. Just giving me that interrupt actually opened up a lot of doors to me.
The CMOS example was great as well. Yes, I know C (along with many other languages), but I am still in my Assembly infancy. I am not looking for an easy way, but I always believe that the forums are a great way to find information that cannot easily be pieced together. Just giving me that interrupt actually opened up a lot of doors to me.
Re: Time and Date
Posted: Mon Apr 23, 2012 9:55 pm
Hi,
The problem with Int 0x1A and the problem with the CMOS is that you can't know which time it has been set to. It could be local daylight savings time for the current time zone, or it could be UTC. You have to ask the user what it's set to when the OS is installed (and hope the system's time isn't changed to a different time zone later) and store that information somewhere so that you can know when the OS starts.
For UEFI, the "GetTime()" function returns a structure containing a bunch of time related fields (year, month, day, etc) that includes a "TimeZone" field and a "Daylight" set of flags. The "TimeZone" field gives you the offset in minutes from GMT, but may be set to "EFI_UNSPECIFIED_TIMEZONE" (and if it is you're meant to assume the time is local time without knowing which time zone). For the "Daylight" set of flags, one flag tells you if the time should be adjusted for daylight savings time (not if it has), and another tells you if the time has been adjusted for daylight savings time (not if it should have been).
Also note that there's no way for the UEFI firmware to keep track of daylight savings time correctly. For many areas of the world, daylight savings is determined by politicians each year and can't be predicted. This means that even if the firmware includes a massive time zone database there's no way (other than firmware updates) to keep this massive time zone database up to date. Instead I assume it's up to the OS maintain a time zone database and update the firmware's time when daylight savings changes occur via. the "SetTime()" function.
Basically what I'm saying is that you can get a time, but figuring out which time you've got is a nightmare. In general, a smart person would say "use UTC for the firmware's time or else" (so that at least the OS would know which time it got). This is actually common practice for Unix and *nix clones.
Sadly (possibly due to Microsoft's stupidity and/or historical reasons dating back to the dark old days of DOS) smart people seem scarce - no smart people were present when the CMOS was designed, no smart people were present when the 80x86 BIOS function was designed, and no smart people were present when the UEFI time services were designed.
Cheers,
Brendan
The problem with Int 0x1A and the problem with the CMOS is that you can't know which time it has been set to. It could be local daylight savings time for the current time zone, or it could be UTC. You have to ask the user what it's set to when the OS is installed (and hope the system's time isn't changed to a different time zone later) and store that information somewhere so that you can know when the OS starts.
For UEFI, the "GetTime()" function returns a structure containing a bunch of time related fields (year, month, day, etc) that includes a "TimeZone" field and a "Daylight" set of flags. The "TimeZone" field gives you the offset in minutes from GMT, but may be set to "EFI_UNSPECIFIED_TIMEZONE" (and if it is you're meant to assume the time is local time without knowing which time zone). For the "Daylight" set of flags, one flag tells you if the time should be adjusted for daylight savings time (not if it has), and another tells you if the time has been adjusted for daylight savings time (not if it should have been).
Also note that there's no way for the UEFI firmware to keep track of daylight savings time correctly. For many areas of the world, daylight savings is determined by politicians each year and can't be predicted. This means that even if the firmware includes a massive time zone database there's no way (other than firmware updates) to keep this massive time zone database up to date. Instead I assume it's up to the OS maintain a time zone database and update the firmware's time when daylight savings changes occur via. the "SetTime()" function.
Basically what I'm saying is that you can get a time, but figuring out which time you've got is a nightmare. In general, a smart person would say "use UTC for the firmware's time or else" (so that at least the OS would know which time it got). This is actually common practice for Unix and *nix clones.
Sadly (possibly due to Microsoft's stupidity and/or historical reasons dating back to the dark old days of DOS) smart people seem scarce - no smart people were present when the CMOS was designed, no smart people were present when the 80x86 BIOS function was designed, and no smart people were present when the UEFI time services were designed.
Cheers,
Brendan