Just looking at std.date, and noticing that
- it isn't object-oriented
- it isn't exactly complete
- its way of dealing with time zones leaves something to be desired

I reckon one of us ought to come up with a good date/time type for D. Has anyone written one already?

Things I feel such a type should support:

- construction by components (obviously)

- properties to set/get component values (obviously) (dealing with out-of-range values is a matter for debate)

- date/time arithmetic

- time zone information in the date object itself, and conversions between time zones

- time zone offset specifiable in minutes, allowing for the half-hour and even quarter-hour time zones that exist (and possibly more exotic, finer offsets)

- conversion to/from human-readable date/time strings, in a standard format and in the display date/time format specified in the OS configuration

- a struct representation that can be read/written from/to a file (either as date only, time only or both)

- possibly conversion to/from d_time, for the purposes it may continue to serve

- the option of specifying only a date, or only a time, if that's what's desired

....

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.

On Mon, 05 Jul 2004 12:10:31 +0100, Stewart Gordon <smjg_1998@yahoo.com> wrote:
>Things I feel such a type should support:

...let me add to that:

* Recognition of various system epochs (I'd love to be able to get a date value, as an offset from the UNIX epoch, even when I'm on a Windows system).

* Ability to toggle on/off daylight savings time adjustments for any given date object, based on its locale.

Benji Smith wrote:
<snip>
> * Recognition of various system epochs (I'd love to be able to get a date value, as an offset from the UNIX epoch, even when I'm on a Windows system).

Yes, there are various date numbering systems.  Unix epochs, at least two systems of Excel dates, Julian dates, the list goes on.  But yes, supporting them would be a step forward.

> * Ability to toggle on/off daylight savings time adjustments for any given date object, based on its locale.

Yes, we could start to list every time locale (combination of standard time offset and DST formula) on the planet, and use it for this.

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.

Stewart Gordon wrote:
> Benji Smith wrote:
> <snip>
> 
>> ...
> 
> Yes, we could start to list every time locale (combination of standard time offset and DST formula) on the planet, and use it for this.
> 
> Stewart.
> 

How about using a 64 bit (128bit?) integer and listing milliseconds (microseconds), +/- since 2004/01/01?  Nice, straightforwards, easy to work with, reasonably compact...the only problem is converting it to a date that anyone else could understand.  And then there's the leap second problem...yes, conversion to standard time might be difficult, if you wanted accuracy closer than a minute. (Over a period of a few centuries.)

Now SETTING it to the implied accuracy...THAT might be a challenge.

Charles Hixson wrote:

<snip>
> How about using a 64 bit (128bit?) integer and listing milliseconds (microseconds), +/- since 2004/01/01?  Nice, straightforwards, easy to work with, reasonably compact...the only problem is converting it to a date that anyone else could understand.  And then there's the leap second problem...yes, conversion to standard time might be difficult, if you wanted accuracy closer than a minute. (Over a period of a few centuries.)
> 
> Now SETTING it to the implied accuracy...THAT might be a challenge.

Internal date representations come in two basic kinds: numerical and structured.

One of my ideas is to have 10 bytes: 4 for date (structured), 4 for time (milliseconds) and 2 for time zone.  That would allow for straightforward date manipulations, and a compact format for the time component (which is much simpler to deal with than dates, so I suppose we can get away with it).

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 <cclpt4$1sv6$1@digitaldaemon.com>, Stewart Gordon says...
>
>Internal date representations come in two basic kinds: numerical and structured.
>
>One of my ideas is to have 10 bytes: 4 for date (structured), 4 for time (milliseconds) and 2 for time zone.  That would allow for straightforward date manipulations, and a compact format for the time component (which is much simpler to deal with than dates, so I suppose we can get away with it).

I would imagine it would simplify things enormously if you dispensed with the time zone field and simply decreed that all dates were to be stored internally in UTC. You would then need to worry about timezones only on creation and extraction - not during date comparisons or manipulations.

This would also mean that you also wouldn't have to worry about daylight saving times, except during creation and extraction. (I didn't see any mention of DST in your above description, by the way. I assume this was an oversight).

In addition, Charles Hixon mentioned the problem of leap seconds. He is correct. You /will/ need to worry about this - if you want to be accurate. Unless of course, you want to store your time information in TAI (International Atomic Time) instead of UTC (Coordinated Universal Time). TAI does not have leap seconds, but can differ from UTC by an integral number of seconds. You might find you need to structure your time field as well as your date field, for reasons such as this!

Of course, no other computer language gets this right, so there's plenty of precedent for pretending that a tropical year is an integral number of seconds for computational convenience. (As if!) But that doesn't make it correct.

Arcane Jill

Arcane Jill wrote:

<snip>
> I would imagine it would simplify things enormously if you dispensed with the
> time zone field and simply decreed that all dates were to be stored internally
> in UTC. You would then need to worry about timezones only on creation and
> extraction - not during date comparisons or manipulations.

Manipulations frequently include manipulation of local times, including DST adjustments.  E.g. in calendar applications.

> This would also mean that you also wouldn't have to worry about daylight saving
> times, except during creation and extraction. (I didn't see any mention of DST
> in your above description, by the way. I assume this was an oversight).
> 
> In addition, Charles Hixon mentioned the problem of leap seconds. He is correct.
> You /will/ need to worry about this - if you want to be accurate. Unless of
> course, you want to store your time information in TAI (International Atomic
> Time) instead of UTC (Coordinated Universal Time). TAI does not have leap
> seconds, but can differ from UTC by an integral number of seconds. You might
> find you need to structure your time field as well as your date field, for
> reasons such as this!
<snip>

Leap seconds are irregular, so they'd need to be either specified by the individual programmer or we'd need to frequently update the module.  A typical desktop computer has even less idea when they occur (except possibly under certain network time servers) so trying to adjust to timing across it would seem fruitless anyway.  For that matter, are there many practical applications rely on that leap second?  As you say, just carrying the time in UTC would simplify things.

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 <ccltm8$22i4$1@digitaldaemon.com>, Stewart Gordon says...

>Manipulations frequently include manipulation of local times, including DST adjustments.  E.g. in calendar applications.

Obviously, but by storing dates internally in timezone-independent form would simplify things greatly. UTC is timezone-independent.


>Leap seconds are irregular,

So is DST, but I don't hear anyone suggesting we ignore that. (See my next
paragraph).


>so they'd need to be either specified by the individual programmer or we'd need to frequently update the module.

Not that frequently. You could pull leap second information off the internet easily enough (the US Navy maintain pretty good tables), and once a year should be sufficient. A table of historic leap seconds and the NTP time when each occurred is available via FTP from any NIST NTP server.

You're going to have to do that ANYWAY to get daylight saving time information. For example, DST in the UK is defined by an act of parliament. Current legislation defines DST here only up to the year 2007. Beyond that, we have to wait for the next act of parliament. I don't know the situation in other parts of the world, but I imagine the rules are similar.


>A typical desktop computer has even less idea when they occur

Isn't that just because of limitations of existing date functions?


>For that matter, are there many practical applications rely on that leap second?

Astronomy? Counting down to a New Year party?

Seriously - the Unix world is cottoning on to this. ISO C 200X proposes a new <time.h> which addresses the leap second question - see http://www.cl.cam.ac.uk/~mgk25/time/c/. Maybe once upon a time clocks weren't accurate enough to worry about it, but they are now, and a language of the future would be seriously dumb to ignore it.

And - (this is completely obvious if you think about it) - those seconds ACCUMULATE. It may only be one or two seconds a year, but over time, they will add up.




>As you say, just carrying the time in UTC would simplify things.

I think you must have misread me. UTC /DOES/ have leap seconds. Carrying the time in UTC would mean that you /DO/ have to worry about them. It's TAI that doesn't.

Calculations would be simpler in TAI, of course, but civil time is based on UTC, not on TAI.

Getting dates right is hard work - but that, of course, is why it would be good to have a library class that gets it right. Otherwise we'd all be rolling our own, over and over again.

Jill

In article <ccbcv8$1lpt$1@digitaldaemon.com>, Stewart Gordon says...
>
>Just looking at std.date, and noticing that
>- it isn't object-oriented
>- it isn't exactly complete
>- its way of dealing with time zones leaves something to be desired

Going back to this original post...

I realise that some of later replies may have focused to heavily on how hard it is to get this right, and that that was perhaps not the best thing for me to have said, because it could be seen as discouragement. I suppose, in my mind, I want D to reach for the stars, to lead the field, not to trail behind other rivals.

But I should instead have been more encouraging. Yes, there is room for improvement in std.date. If someone were to write something better, I don't think anyone would complain. As D advances, I think we are going to see /many/ of our "old favorites" in std.whatever get superceded by superior alternatives. And these in turn may be superceded yet again. At this early stage in D's development, I do believe we should encourage such progress.


>I reckon one of us ought to come up with a good date/time type for D. Has anyone written one already?

Not in D, but in C++ many, many times. And each time differently - and I only ever wrote in the functionality that I, personally, needed, and no more. I suspect lots of other people have done the same. Why? Because existing date functionality on many platforms is not that good.

And of course, it was DST that I found hardest of all. Where do you get all that information for every locale in the world and for every year, past, present and future?

But anyway - here are my thoughts, if someone should care to code them up. This is a general idea, which may be improved upon over time without having to go back and rewrite everything. Stuff like DST and leap-seconds can be added later, without breaking the API.

I envisage at least TWO classes/structs. One - (probably called Date) - represents a single instant in time. It doesn't matter what that instant is /called/, it only matters that two Dates compare equal if and only if they represent the same instant in time. Dates should also be comparable with each other using opCmp.

Two - a class/struct (probably called either DateDiff or Interval) - which represent the difference between two dates. Like Date itself, the internal format is irrelevant, only the API matters.

Operator overloads should do the expected thing. A Date plus a DateDiff gives another Date. Subtracting a Date from a Date gives a DateDiff. Both Date and DateDiff have functions to do various conversions.

I hope someone takes this up, as it would be a really good thing to have.


>Things I feel such a type should support:
>
>- construction by components (obviously)
>
>- properties to set/get component values (obviously) (dealing with out-of-range values is a matter for debate)
>
>- date/time arithmetic

Yes.


>- time zone information in the date object itself, and conversions between time zones

This is the part with which I disagree. If a Date represents a specific instant in time then it HAS no time-zone. It is just a moment in time. For example, in Jill's scheme, if a user in France and a user in America both constructed a Date object to represent the instant in time when Neil Armstrong first set foot on the moon, those two objects would compare equal. Timezone is not relevant. If either or both of these passed such an object to a user in Japan, they would be able to extract from it the Japanese local time which represents that instant.

Timezone is a conversion problem. You need to know it when you CONSTRUCT a Date, and you need to know the timezone for which you require information when you EXTRACT infomation from a Date, but you don't need to store timezone information IN a Date.


>- time zone offset specifiable in minutes, allowing for the half-hour and even quarter-hour time zones that exist (and possibly more exotic, finer offsets)

A TimeZone class/struct wouldn't be a bad idea then, but again, there is no need to store a timezone inside a Date. That's confusing two concepts.


>- conversion to/from human-readable date/time strings, in a standard format and in the display date/time format specified in the OS configuration
>
>- a struct representation that can be read/written from/to a file (either as date only, time only or both)
>
>- possibly conversion to/from d_time, for the purposes it may continue to serve
>
>- the option of specifying only a date, or only a time, if that's what's desired


I hope someone takes this up. With the concept I've suggested, and the feature list that Stewart has suggested, this would be a marvellous thing. Extra goodies like proper DST/leap second support could then always be added later, without breaking anything.

Jill

Arcane Jill wrote:

<snip>
> This is the part with which I disagree. If a Date represents a specific instant
> in time then it HAS no time-zone. It is just a moment in time. For example, in
> Jill's scheme, if a user in France and a user in America both constructed a Date
> object to represent the instant in time when Neil Armstrong first set foot on
> the moon, those two objects would compare equal. Timezone is not relevant. If
> either or both of these passed such an object to a user in Japan, they would be
> able to extract from it the Japanese local time which represents that instant.

Comparing equal and being identical internally aren't the same thing. But yes, you have a point.

> Timezone is a conversion problem. You need to know it when you CONSTRUCT a Date,
> and you need to know the timezone for which you require information when you
> EXTRACT infomation from a Date, but you don't need to store timezone information
> IN a Date.
<snip>

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.

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.