View mode: basic / threaded / horizontal-split · Log in · Help
July 05, 2004
Replacement for/alternative to std.date?
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.
July 06, 2004
Re: Replacement for/alternative to std.date?
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.
July 06, 2004
Re: Replacement for/alternative to std.date?
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.
July 08, 2004
Re: Replacement for/alternative to std.date?
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.
July 09, 2004
Re: Replacement for/alternative to std.date?
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.
July 09, 2004
Re: Replacement for/alternative to std.date?
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
July 09, 2004
Re: Replacement for/alternative to std.date?
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.
July 09, 2004
Re: Replacement for/alternative to std.date?
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
July 10, 2004
Re: Replacement for/alternative to std.date?
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
July 12, 2004
Re: Replacement for/alternative to std.date?
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.
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home