In article <ccu396$1q3o$1@digitaldaemon.com>, Stewart Gordon says...
>
>Arcane Jill wrote:
>
>Yes, I suppose you have a good idea there.  Of course we should have a means of selecting the time zone in which these functions are carried out, which would obviously default to the user's local time zone.

I think you're right too. I mean, we're both right.

I think you're talking about expressing partial information about a date. You mentioned being able to express a date without a time, or a time without a date. Or - other examples spring to mind immediately - a day, month and year, but with calendar (Gregorian or Julian) unspecified.

So I think we need your idea too. Let's call this concept a PartialDate (well, feel free to come up with a better idea). This stores structured information about a date, such a human might use, but doesn't actually refer to an instant in time.

To turn a PartialDate into a Date, you'd need to either supply the missing parts, or pass to a function that used some magic defaults.

I think a "best of both worlds" approach would be pretty cool, actually,

Jill

Arcane Jill wrote:
> In article <ccu396$1q3o$1@digitaldaemon.com>, Stewart Gordon says...
>>Arcane Jill wrote:
>>Yes, I suppose you have a good idea there.  Of course we should have a means of selecting the time zone in which these functions are carried out, which would obviously default to the user's local time zone.
> 
> I think you're right too. I mean, we're both right.
> 
> I think you're talking about expressing partial information about a date. You
> mentioned being able to express a date without a time, or a time without a date.
> Or - other examples spring to mind immediately - a day, month and year, but with
> calendar (Gregorian or Julian) unspecified.
> 
> So I think we need your idea too. Let's call this concept a PartialDate (well,
> feel free to come up with a better idea). This stores structured information
> about a date, such a human might use, but doesn't actually refer to an instant
> in time.
> 
> To turn a PartialDate into a Date, you'd need to either supply the missing
> parts, or pass to a function that used some magic defaults.
> 
> I think a "best of both worlds" approach would be pretty cool, actually,

There have been rather extensive discussions on how to improve on the standard C libraries for date and time handing in the comp.std.c news group, over a period of years in total.  Two links at Google, via Tiny URL, are:

More recent - June-July 2004

http://tinyurl.com/6cy94

Less recent - February-April 2002

http://tinyurl.com/5peb9    -- main thread
http://tinyurl.com/6eagz    -- first side thread
http://tinyurl.com/4wtr4    -- second side thread

http://david.tribble.com/text/c0xcalendar_1.html
http://david.tribble.com/text/c0xcalendar.html
http://david.tribble.com/text/c0xtimet.htm
http://david.tribble.com/text/c0xlongtime.html

http://www.calendarists.com/

I have a bunch of URLs for other more or less relevant web sites discussing many of the issues.  At the very least, people designing a system for D should be aware of the issues facing other languages - and be grateful for the lack of legacy code to hamper getting your changes accepted.

-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

I've now got an idea I think I'm going to try and code up.  (That is, if I don't end up discarding this one for another one as I have been doing for the last however long.)

Two structs, DateValue and TimeValue, will each wrap a 32-bit integer representing a date and a UTC time respectively, and provide operations on them.

A third struct, DateTime, would combine these values and provide operations that rely on the combination (as local time manipulation nearly always does).

Operations that get/set components would work in local time, which would default to the user's time zone but be globally settable.

Further types could represent intervals of time on a similar basis.

This system would, I believe, make it fairly straightforward to add improvements such as DST adjustment and leap seconds at some later date.

As an extra, we could have a struct of the date/time components (of which some may be 'blank'), and conversions between this and the aforementioned types.

What does everyone think?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <cd3mj8$2cai$1@digitaldaemon.com>, Stewart Gordon says...
>
>I've now got an idea I think I'm going to try and code up.  (That is, if I don't end up discarding this one for another one as I have been doing for the last however long.)
>
>Two structs, DateValue and TimeValue, will each wrap a 32-bit integer representing a date and a UTC time respectively, and provide operations on them.
>
>A third struct, DateTime, would combine these values and provide operations that rely on the combination (as local time manipulation nearly always does).
>
>Operations that get/set components would work in local time, which would default to the user's time zone but be globally settable.
>
>Further types could represent intervals of time on a similar basis.
>
>This system would, I believe, make it fairly straightforward to add improvements such as DST adjustment and leap seconds at some later date.
>
>As an extra, we could have a struct of the date/time components (of which some may be 'blank'), and conversions between this and the aforementioned types.
>
>What does everyone think?

I love this idea Stewart. :)

Are you going to include a 'free-format' function as well as explicit methods?

// future example?
DateValue dv = new DateValue(someTimeUint);
writefln("The date is: %s",dv.format("MM/DD/YYYY"));
TimeValue tv = new TimeValue(someTimeUint);
writefln("The time is: %d:%d:%d",dt.hours(),dt.minutes(),dt.seconds());

- Pragma

pragma <EricAnderton at yahoo dot com> wrote:

<snip>
> Are you going to include a 'free-format' function as well as explicit methods?
> 
> // future example?
> DateValue dv = new DateValue(someTimeUint);
> writefln("The date is: %s",dv.format("MM/DD/YYYY"));

Good question.  I guess it's a matter of how useful it would be over the OS format and what can be done with writef.

> TimeValue tv = new TimeValue(someTimeUint);
> writefln("The time is: %d:%d:%d",dt.hours(),dt.minutes(),dt.seconds());

dt?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <cd3s07$2l0c$1@digitaldaemon.com>, Stewart Gordon says...
>
>pragma <EricAnderton at yahoo dot com> wrote:
>
><snip>
>> Are you going to include a 'free-format' function as well as explicit methods?
>> 
>> // future example?
>> DateValue dv = new DateValue(someTimeUint);
>> writefln("The date is: %s",dv.format("MM/DD/YYYY"));
>
>Good question.  I guess it's a matter of how useful it would be over the OS format and what can be done with writef.

(Stewart, I hope you don't mind me expanding on your concept BTW, as I have a few more ideas regarding dates in D myself.)

The only reason why I bring up string-based formatting of dates is because, sooner or later, you're going to want to generate a string representation of a date without wrangling a huge lump of code.  This is just like how printf/writef is more useful (if not clearer) than streams in some cases.

IMO, Anything that follows the same formatting conventions as PHP's date() function  would be *extremely* useful:

http://us2.php.net/date

BTW, that URL is *packed* with useful functions waiting to be added to D.

As a side note, I'd even advocate having a '%t' format specifier for d_time added to std.format if nothing else.  Right now, d_time is dumped as a ulong.

> //get the time
> d_time dt = getUTCtime();
>
> // just dump the time in much the same way toDateString() does.
> writefln("timestamp: %t",dt);
>
> //use '#' to flag the alternative format which uses a format arg writefln("Today is: %#t","MM/DD/YYYY",dt);

If you're not adverse to the d_time type, then perhaps the same formaters could also be used to getwhatever bits we want:

>  // these could be added to std.date...?
>  uint getDatePart(d_time dt,char[] dateFormat);
>  char[] getDatePartString(d_time dt,char[] dateFormat);

I think both your class(es) and such a format extension could live quite happily
side-by-side. :)

>
>> TimeValue tv = new TimeValue(someTimeUint);
>> writefln("The time is: %d:%d:%d",dt.hours(),dt.minutes(),dt.seconds());
>
>dt?

erg.. 'tv' for TimeValue rather.  I'm used to 'dt' for 'd_time'.

- Pragma

Stewart Gordon wrote:

> I've now got an idea I think I'm going to try and code up.  (That is, if I don't end up discarding this one for another one as I have been doing for the last however long.)
> 
> Two structs, DateValue and TimeValue, will each wrap a 32-bit integer representing a date and a UTC time respectively, and provide operations on them.
> 
> A third struct, DateTime, would combine these values and provide operations that rely on the combination (as local time manipulation nearly always does).
> 
> Operations that get/set components would work in local time, which would default to the user's time zone but be globally settable.
> 
> Further types could represent intervals of time on a similar basis.
> 
> This system would, I believe, make it fairly straightforward to add improvements such as DST adjustment and leap seconds at some later date.
> 
> As an extra, we could have a struct of the date/time components (of which some may be 'blank'), and conversions between this and the aforementioned types.
> 
> What does everyone think?

Sub-second precision?  Please?

And the 'UTC time'; what range do you have in mind?  Within a single day, or since 1970-01-01 00:00:00+00:00, or some other epoch?


-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Jonathan Leffler wrote:
<snip>
> Sub-second precision?  Please?
> 
> And the 'UTC time'; what range do you have in mind?  Within a single day, or since 1970-01-01 00:00:00+00:00, or some other epoch?

My thought is that TimeValue would represent a time within a single day, in milliseconds since midnight UTC.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

pragma <EricAnderton at yahoo dot com> wrote:
<snip>
> The only reason why I bring up string-based formatting of dates is because,
> sooner or later, you're going to want to generate a string representation of a
> date without wrangling a huge lump of code.  This is just like how printf/writef
> is more useful (if not clearer) than streams in some cases.

The only trouble with streams is that writef hasn't been put into them.  I've written the code to do this and posted it here the other day ... hopefully they'll actually be put in.

> IMO, Anything that follows the same formatting conventions as PHP's date()
> function  would be *extremely* useful:
> 
> http://us2.php.net/date

Had a look.  The assignment of letters to formats looks rather inconsistent, but at least it would be easy to parse.

I've noticed that that system doesn't seem to have:

- case control over day and month names
- any mention of BC/AD, presumably because BC is beyond the PHP date range...

> BTW, that URL is *packed* with useful functions waiting to be added to D.
> 
> As a side note, I'd even advocate having a '%t' format specifier for d_time
> added to std.format if nothing else.  Right now, d_time is dumped as a ulong.
<snip>
>> //use '#' to flag the alternative format which uses a format arg
>> writefln("Today is: %#t","MM/DD/YYYY",dt);

We'd have to decide on a system for format strings.

I had been thinking about a system like this:

dd MMM yyyy			15 JUL 2004
Wwww 'the' ddt 'of' Mmmm	Thursday the 15th of July
h:ii:ss	pp			4:25:10 pm
HH:ii:ss			16:25:10
yyyy-mm-dd HH:ii:ss.lll		2004-07-15 16:25:10.254

....

> If you're not adverse to the d_time type, then perhaps the same formaters could
> also be used to getwhatever bits we want:

I suppose my date types and d_time could continue to be developed in parallel for a while.

>> // these could be added to std.date...?
>> uint getDatePart(d_time dt,char[] dateFormat);
>> char[] getDatePartString(d_time dt,char[] dateFormat);

What would those functions return exactly, for different dateFormat strings?

> I think both your class(es) and such a format extension could live quite happily
> side-by-side. :)
<snip>

Yes.  Once we've all settled for a suitable format format, it could be integrated into both d_time and my types.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <cd68nd$271p$1@digitaldaemon.com>, Stewart Gordon says...
>The only trouble with streams is that writef hasn't been put into them.
>  I've written the code to do this and posted it here the other day ...
>hopefully they'll actually be put in.

Amen to that.  A streams extension to writef would be dead-simple to write too.

>> IMO, Anything that follows the same formatting conventions as PHP's date() function  would be *extremely* useful:
>> 
>> http://us2.php.net/date
>
>Had a look.  The assignment of letters to formats looks rather inconsistent, but at least it would be easy to parse.

Agreed.  Its a starting point though.  Oracle has it's own way of doing this as well: http://www-db.stanford.edu/~ullman/fcdb/oracle/or-time.html.  This is also a pretty deficent way of accomplishing things.

The ISO spec for date/time formatters is a good reference too, but doesn't have as many bells and whistles: http://www.cl.cam.ac.uk/~mgk25/iso-time.html.  The page does include a link to an algorithm database for timezones and daylight savings time algorithms that might pique your interest: http://www.twinsun.com/tz/tz-link.htm.

>I've noticed that [the php date] system doesn't seem to have:
>
>- case control over day and month names
>- any mention of BC/AD, presumably because BC is beyond the PHP date
>range...

I never thought of this, but you're right. Php falls completely flat in this department. I was thinking you could use "ad" for "bc/ad" notation and "ce" for "ce/bce" notation, but this creates trouble by conflicting with other notations in the spec.  To include these features, something new might be needed.

>
>> BTW, that URL is *packed* with useful functions waiting to be added to D.
>> 
>> As a side note, I'd even advocate having a '%t' format specifier for d_time added to std.format if nothing else.  Right now, d_time is dumped as a ulong.
><snip>
>>> //use '#' to flag the alternative format which uses a format arg writefln("Today is: %#t","MM/DD/YYYY",dt);
>
>We'd have to decide on a system for format strings.
>
>I had been thinking about a system like this:
>
>dd MMM yyyy			15 JUL 2004
>Wwww 'the' ddt 'of' Mmmm	Thursday the 15th of July
>h:ii:ss	pp			4:25:10 pm
>HH:ii:ss			16:25:10
>yyyy-mm-dd HH:ii:ss.lll		2004-07-15 16:25:10.254

Sounds like a soild start.  I may throw some suggestions for this back into the NG later, if you like? :)

>>> // these could be added to std.date...?
>>> uint getDatePart(d_time dt,char[] dateFormat);
>>> char[] getDatePartString(d_time dt,char[] dateFormat);
>
>What would those functions return exactly, for different dateFormat strings?

Well it may not be that useful, but something like:

> int day = getDatePart(dt,"dd"); // returns the day
> char month = getDatePartString(dt,"Mmmm"); // returns month like 'July'.

.. but that's probably not as useful as I would have first thought.

- Pragma