Is there any method to acquire the time and date in C without using #include <time.h>?
Inline Assembly maybe? A call to BIOS?
[Solved] Time and Date
[Solved] Time and Date
Last edited by kammce on Mon Apr 23, 2012 6:53 pm, edited 1 time in total.
Re: Time and Date
Interrupt 0x1A
Re: Time and Date
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
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
Maybe this is what you're looking for? http://wiki.osdev.org/CMOS
Re: Time and Date
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
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
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.