|
|
Home » U++ Library support » U++ Core » Time::Set(int64 scalar) unexpected results
Time::Set(int64 scalar) unexpected results [message #40730] |
Tue, 10 September 2013 20:14  |
 |
Alboni
Messages: 216 Registered: January 2012 Location: Kajaani, Finland
|
Experienced Member |
|
|
This is about
void Date::Set(int scalar)
Assign a date that is stored in the numeric scalar.
and
void Time::Set(int64 scalar)
Assign a time that is stored in the numeric scalar.
When I assign a unix time with Time::Set, the year is 43 instead of 2013. The origin of that problem seems to be in Date::Set(int scalar)
Is this a bug or is the Upp timesystem not starting in 1970 but in the year 0? scalar values obtained from Time::Get() do work.
I fixed it in my program like this (for now) :
int64 unixtime = ..........
Time timestamp;
time.Set(unixtime);
time.year+=1970;
What would be the correct way to import a unix time?
[Updated on: Tue, 10 September 2013 20:40] Report message to a moderator
|
|
|
|
Re: Time::Set(int64 scalar) unexpected results [message #40732 is a reply to message #40730] |
Tue, 10 September 2013 20:52   |
|
Hi Alboni,
That is not a bug, it is just how the Time in U++ is designed. Unix timestamp is 32bit number, describing times from 1.1.1970 to someday in 2038. U++ Time works for dates from 4000 B.C. to 4000 A.D. if I remember correctly.
Maybe there is an explicit method to convert the timestamp to Time that I don't know about... But AFAIK the simplest way (at least on POSIX) is to use FileTime, which is just a wrapper around time_t.
So you should be able to doTime t = FileTime(timestamp);
Another possible solution, that should IMHO work correctly even on windows, could be something likeconst Time epoch(1970,1,1);
Time t;
t.Set(epoch.Get()+timestamp);
Best regards,
Honza
PS: You're right about U++ intentionally using year 0 as a center point for time. As it uses signed type, it allows for both negative and positive values so it can accurately represent about 8000 years timespan.
[Updated on: Tue, 10 September 2013 20:55] Report message to a moderator
|
|
|
|
|
Re: Time::Set(int64 scalar) unexpected results [message #40735 is a reply to message #40733] |
Tue, 10 September 2013 21:04   |
|
Alboni wrote on Tue, 10 September 2013 20:54 | time_t can be both 32 or 64 bit
| Yes, it is implementation defined. It doesn't even have to start at 1970 :http://en.cppreference.com/w/c/chrono/time_t | Arithmetic type capable of representing times.
Although not defined, this is almost always a integral value holding the number of seconds (not counting leap seconds) since 00:00, Jan 1 1970 UTC, corresponding to POSIX time.
| So it would be safer not to rely on it too much, especially if you want the app to be platform independent.
Alboni wrote on Tue, 10 September 2013 20:54 | and the rest work ok. just not the year.
| All the years are quite similar, unless it is a leap year. I'd say that just changing the year after using Time::Set() with timestamp might mess up something due to the complex rules of leap days (see Date::Set(int64) to get an idea how complex this stuff is ).
Honza
[Updated on: Tue, 10 September 2013 21:04] Report message to a moderator
|
|
|
|
Goto Forum:
Current Time: Sat Apr 26 20:33:10 CEST 2025
Total time taken to generate the page: 0.00837 seconds
|
|
|