[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MiNT] timezone change
Hi Guido!
GF>And Minix and Ext2 wants RTC = UTC.
Do Minix and Ext2 read their time directly from the RTC?
I don't think so, I think they get it from the kernel (else they are
misdesigned, IMO).
So they do not require RTC = UTC, they require the kernel to pass the time in
UTC. That's a big difference
GF>And TOS gets local time. That matters.
TOS gets it's time directly from the RTC, so it requires RTC = local time
So if you use TOS there is a clear advantage if you have RTC = local time.
But that doesn't hinder MiNT from working with UTC. The only thing MiNT has
to do for that is to convert the time it gets from the RTC to UTC (everytime,
when the RTC is accessed, but only then).
GF>Unix UTC timestamps are simply an integer number (the number of
GF>seconds since Jan 1, 1970, 0:00 UTC). GEMDOS timestamps are broken-
GF>down (i. e. hour, minute, second, day, month, year are all stored in a
GF>separate integer value).
That's right, but the timestamp format is independend from the time base (UTC
or local time)
Besides that:
GF>Add a second to a GEMDOS timestamp:
In this situation you can asume the GEMDOS time stamp to be valid which
allows it to reduce the costs significantly by restructuring the code like
this:
seconds++;
if (seconds > 59 && not_by_accident_a_leap_second)
{
seconds = 0;
minutes++;
if (minutes > 59)
{
minutes = 0;
hours++;
if (hours > 23)
{
hours = 0;
day++
switch (month)
{
case february: if (day > 28)
{
if (leap_year && day <= 29)
break
...
}
break;
case january:
case march:
...
if (day > 31)
...
break;
case april:
case june:
...
if (day > 30)
...
break;
}
}
}
}
This is certainly more expensive than the single addition with unix
timestamps, but it's not as bad as your code suggested
Bye
Joerg