Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Core » Time and Date
Time and Date [message #11277] Thu, 30 August 2007 11:53 Go to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
I've been looking at making a patch to fix EditTime and and some other related stuff, but I've hit a serious problem - There is no way to represent just a time in Upp. For instance:
		Time t;
		t.hour = 14;
		t.minute = 13;
		t.second = 12;
		time <<= t;
		bool isvalid = t.IsValid();
		bool isnull = IsNull(t);
		String asstring = AsString(t);

Output:
isvalid = true
isnull = true
asstring = null

This is caused by:
template<> inline bool  IsNull(const Time& t)    { return t.year == -32768; }


Personally I think Date and Time should be seperated (and have an additional DateTime class) but can see this might be impractical at this stage. However, could this also be fixed by having a null state for Time (like minute or second >= 60) and test for that instead?

James

[Updated on: Thu, 30 August 2007 12:16]

Report message to a moderator

Re: Time and Date [message #11280 is a reply to message #11277] Thu, 30 August 2007 16:27 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Hm, what about representing the time just by number of seconds?

In fact, the main purpose of both Date and Time structs is that they understand calendar...

As for Time representing just time in day, well, maybe it would be sound design choice, however, right now, it is too late for such radical change. If number of second is not going to help here, we have to invent some new name, like "TimeInDay" or something...

Mirek
food for thought [was: Time and Date] [message #11283 is a reply to message #11280] Thu, 30 August 2007 19:38 Go to previous messageGo to next message
ebojd is currently offline  ebojd
Messages: 225
Registered: January 2007
Location: USA
Experienced Member
Over on the Spirit++ forum we've had a couple of discussions over the years about how to deal with similar issues. There are a number of standars (such as ISO 8601) which describe how and why various things are being done. In addition to that, I ran into a problem a couple of decades ago where I needed to describe date and time ranges for a variety of modeling and paleological database management.

When modeling events over geological timeframes you can run into some odd things where you know that an event happened in the morning (because a flower that only blooms in the morning, during about a given month) was embedded into sediment. From this you can deduce the sample was "collected/fixed" April 15 (+/-15 days), 7:00am (+/-1:00) 25,000 BCE (+/- 5,000)... How do you represent various errors and/or ranges... At the moment I have a bunch of LIDAR processing I am working towards and need to be able to track the real-time laser shots down to the us or finer.

Also, there are numerous calendars and actually different ways to measure time (sorry I do not have the references on me but I might be able to point you to them if interested). So there is an implied issue of separating the presentation from the actual date/time variable.

In the end, it is very difficult to design a widely applicable date/time parser/module. I would first ask what your applications are.

Anyway, food for thought.

EBo --
Re: food for thought [was: Time and Date] [message #11290 is a reply to message #11283] Fri, 31 August 2007 12:38 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
ebojd wrote on Thu, 30 August 2007 18:38

Anyway, food for thought.

A feast Smile

I agree with both of you. It's definitely impractical to fundamentally change the current Date/Time structure - besides the large amount of work this would break far to much code - and I agree that it's futile attempting to devise a design that is going to be applicable to all situations.

My concern really originates from the fact that currently Upp handles this issue is a very unfriendly way. EditTime in particular doesn't do what you'd expect it to and is essentially useless (I can't think of any reason why you would want to use it instead of two seperate Time/Date fields). And because of the EditField/Convert concept the reason and solution to this is not obvious to new users.

Do you think it would be feasible to change EditTime to return the number of seconds and only accept times? The change is easy to make, but does anyone already use it?

I know this a relatively minor issue, but I've got a bee in bonnet about it now, and I think it's in everyone interest to make Upp as good and easy to learn as possible. Smile

James

EDIT: Changed my mind obout some stuff...

[Updated on: Fri, 31 August 2007 14:47]

Report message to a moderator

Re: food for thought [was: Time and Date] [message #11305 is a reply to message #11290] Mon, 03 September 2007 00:10 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Well, it would needed another name. For good or bad, Time/EditTime already have meaning.

Maybe EditTimeSpan?

Mirek
Previous Topic: NTL vs STL compatibility
Next Topic: 2 small Bugs [bug]
Goto Forum:
  


Current Time: Fri Mar 29 15:32:00 CET 2024

Total time taken to generate the page: 0.03239 seconds