www.digitalmars.com         C & C++   DMDScript  

D - Date & time

reply DrWhat? <DrWhat nospam.madscientist.co.uk> writes:
On the current debate about internationalisation of D,  we know there are 
may different fomats for the date and time in use around the world so how 
about using a standard format for d&t representation (instead of the 
Georgian calendar and standard time (with problems of daylight savings and 
time zone).

I propose we represent the Date in Julian Cycles (international standard 
commonly used in astronomy) minus .5 and the time in seconds (or milli 
seconds) since midnight universal standard time (UST).  Any other formats 
could be calculated from this simple and standard representation avoiding 
errors such as Y2K for several million years if we store the date in 64 bit 
(long) format.  Ie. day of week is Julian cycles % 7.

struct date
{       uint    time    /* 32 bit time */
 ;      ulong   date    /* 64 bit date */
 ;
}

A little info (copied from somewhere on the Internet many years ago - sorry 
lost the URL and it probably no longer exists anyway)

---------------------

What is a Julian date and a modified Julian date?
 
It's the number of days since noon 4713 BCE January 1. What's so special 
about this date?
 
Joseph Justus Scaliger (1540--1609) was a noted Italian-French philologist 
and historian who was interested in chronology and reconciling the dates in 
historical documents. As many calendars were in use around the world this 
created the problem of which one to use. To solve this Scaliger invented 
his own era and reckoned dates by counting days. He started with 4713 BCE 
January 1 because that was when solar cycle of 28 years (when the days of 
the week and the days of the month in the Julian calendar coincide again), 
the Metonic cycle of 19 years (because 19 solar years are roughly equal to 
235 lunar months) and the Roman indiction of 15 years (decreed by the 
Emperor Constantine) all coincide. There was no recorded history as old as 
4713 BCE known in Scaliger's day, so it had the advantage of avoiding 
negative dates. Joseph Justus's father was Julius Caesar Scaliger, which 
might be why he called it the Julian Cycle. Astronomers adopted the Julian 
cycle to avoid having to remember "30 days hath September ...." and to 
avoid the 10/11 day hiatus in the Gregorian calendar.
 
For reference, Julian day 2450000 began at noon on 1995 October 9. Because 
Julian dates are so large, astronomers often make use of a "modified Julian 
date"; MJD = JD - 2400000.5. (Though, sometimes they're sloppy and subtract 
2400000 instead.)

-----------------

There are lots of programmes to convert Julian date to other calendars,  
and adding/subtracting the current time zone and daylight savings info 
should be easy.

This format has the additional benifit that the date and time can be easily 
copied - all that is required is a library (locale.d) which can convert 
this standard format to/from what ever the local format is.

I would have a go at creating this library - but as I do not run Windows I 
am unable to run the D compiler (have to wait for the Solaris or Linux 
version),  I could have a go at specifying it however.

All the best :

C 2002/3/23
Mar 24 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"DrWhat?" <DrWhat nospam.madscientist.co.uk> wrote in message
news:a7koqi$20lc$1 digitaldaemon.com...

 On the current debate about internationalisation of D,  we know there are
 may different fomats for the date and time in use around the world so how
 about using a standard format for d&t representation (instead of the
 Georgian calendar and standard time (with problems of daylight savings and
 time zone).

 I propose we represent the Date in Julian Cycles (international standard
 commonly used in astronomy) minus .5 and the time in seconds (or milli
 seconds) since midnight universal standard time (UST).  Any other formats
 could be calculated from this simple and standard representation avoiding
 errors such as Y2K for several million years if we store the date in 64

 (long) format.  Ie. day of week is Julian cycles % 7.

 struct date
 {       uint    time    /* 32 bit time */
  ;      ulong   date    /* 64 bit date */
  ;
 }


 This format has the additional benifit that the date and time can be

 copied - all that is required is a library (locale.d) which can convert
 this standard format to/from what ever the local format is.

 I would have a go at creating this library - but as I do not run Windows I
 am unable to run the D compiler (have to wait for the Solaris or Linux
 version),  I could have a go at specifying it however.

It could be used as an internal representation, probably. The problem is, D locale system has to be designed first =)
Mar 24 2002
parent reply DrWhat? <blackmarlin nospam.asean-mail.com> writes:
Pavel Minayev wrote:

 It could be used as an internal representation, probably.
 The problem is, D locale system has to be designed first =)

That is the idea - to use a _common_ internal represnetation then design the locale system around that - for example (sorry the syntax is not D - you should be able to understand anyway) class UKLocale is Locale { constant dateFormat = "dd/mm/yyyy" constant hoursDivider = ":" constant minutesDivider = "." ` etc ... method getTime is Unsigned ;;; out Unsigned hours , out Unsigned minutes , out Unsigned seconds , out Unsigned milliSeconds { ` return current time hours = timeSeconds / ( 60*60*1000) minutes = (timeSeconds / (60*1000)) % 60 seconds = (timeSeconds/1000) % 60 milliSeconds = timeSeconds % 1000 return timeSeconds } method getTimeString is Character[] { ` convert time to hours / minutes / seconds getTime.this()( h, m, s, ms ) return toString.h() # toString.m() # toString.s() # toString.ms() } method setTime ;; in Unsigned hours , in Unsigned minutes , in Unsigned seconds , in Unsigned milliseconds { ` convert time into standard format & store timeSeconds = ... } method getDateString ` you get the idea method getDate method setDate } then alias the current local class (CurrentLocale) to what ever this local is (this could be done either at compile time or run time depending on the implementation.
Mar 24 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
news:a7l3d9$2ncu$1 digitaldaemon.com...

 That is the idea - to use a _common_ internal represnetation then design
 the locale system around that - for example (sorry the syntax is not D -
 you should be able to understand anyway)

The idea is great. But it's more than dates, it also needs to cover numbers, monetary, boolean, string equality and comparison etc... and it should be extensible, so you could for example make a (new!) phone number facet and write functions which rely on it.
Mar 24 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a7l75r$4r$1 digitaldaemon.com...
 "DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
 news:a7l3d9$2ncu$1 digitaldaemon.com...

 That is the idea - to use a _common_ internal represnetation then design
 the locale system around that - for example (sorry the syntax is not D -
 you should be able to understand anyway)

The idea is great. But it's more than dates, it also needs to cover numbers, monetary, boolean,

Are there really international differences in the representation of boolean data? Oh my!!!!!!!! What could they possibly be?????? -- - Stephen Fuld e-mail address disguised to prevent spam
Mar 24 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a7ldfq$dto$1 digitaldaemon.com...

 Are there really international differences in the representation of

 data?  Oh my!!!!!!!!  What could they possibly be??????

Translations of English words "true" and "false". By the way, C++ does it, if you enable boolalpha for streams.
Mar 24 2002
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"DrWhat?" <DrWhat nospam.madscientist.co.uk> wrote in message
news:a7koqi$20lc$1 digitaldaemon.com...
 I propose we represent the Date in Julian Cycles (international standard

seconds) since midnight universal standard time (UST). Any other formats could be calculated from this simple and standard representation avoiding errors such as Y2K for several million years if we store the date in 64

 (long) format.  Ie. day of week is Julian cycles % 7.

I think you have a great idea. But I have a question. My existing plan is to represent time as a 64 bit signed quantity of milliseconds since Jan 1, 1970. The nice thing about that is I have a number of tested and debugged functions for coversion to/from that format into more recognizable values. Would I be correct in that conversion of that to/from julian cycles would be simply adding an offset?
 I would have a go at creating this library - but as I do not run Windows I
 am unable to run the D compiler (have to wait for the Solaris or Linux
 version),  I could have a go at specifying it however.

That'd be great.
Mar 24 2002
parent reply DrWhat? <blackmarlin nospam.asean-mail.com> writes:
Walter wrote:
 
 I think you have a great idea. But I have a question. My existing plan is
 to represent time as a 64 bit signed quantity of milliseconds since Jan 1,
 1970. The nice thing about that is I have a number of tested and debugged
 functions for coversion to/from that format into more recognizable values.
 
 Would I be correct in that conversion of that to/from julian cycles would
 be simply adding an offset?

Adding an offset after converting from days - in my opinion julian cycles are not that good at representing time (uses fractions to represent time and looks like a stardate :-), the advantage of julian cycles is that its origin exists at the point where many dating systems coincide. Julian cycles are days since noon BCE4713/1/1 (as mentioned in my previous post), as a day is a fairly standard international concept, counting in days should be the standard international method. The Julian cycles date system has been around for about 450 years (longer than the one we use), is not based on an entirely arbitrary start date and is large enough to contain nearly all of recorded history. A 64 bit count is a good idea but if we count from 1970 then how do we represent dates before then (ie. birthdays - some of which could be as early as 1880) - surely a proprietary format is not a good idea and will decrease interoperability and negitive dates are not pleasant. And frequently we would want the date separate from the time - supplying both lumped together could be misleading, though concatenating the two is simple. Finally taking count of leap seconds could pose a problem, as i believe they are not added on a standard basis - anyone have info on this? Though in my proposal the suggestion of a 64 bit value for the date was in reflection a little excessive - 32 bit would be ok for near a million years - after that you can respecify it :-) Your format does have one advantage - it would still be applicable on other planets, though I do not expect that to be a major concern for a while yet, and the locale module could take care of varying seconds in the day.
 I would have a go at creating this library - but as I do not run Windows
 I am unable to run the D compiler (have to wait for the Solaris or Linux
 version),  I could have a go at specifying it however.

That'd be great.

Ok, as I am working on a similar project I could use that and convert to D. Of course there will be a lot more to do than just time & date - measurement, decimal points, numbers 1 000 000 000 .000 1,000,000,000.000 1.000.000.000,000 etcetera... , currency ($), string compare, case conversion (just knowing what is a letter and what is not), daylight savings, time zones and probably a few other bits and bobs (anything obvious I have missed - by the way I would not include boolean translations ie. FALSE -> FALSCH, FAUX, etcetera. - they would be better either represented with a symbol [tick / cross] - the unicode character of which could be returned from a method or translated with the remainder of the programme if a new language is required). (hmm ... have to find that book in the library about international date systems to start with.) C 2002/3/24
Mar 25 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
news:a7n7d3$2cv1$1 digitaldaemon.com...

 A 64 bit count is a good idea but if we count from 1970 then how do we
 represent dates before then (ie. birthdays - some of which could be as
 early as 1880) - surely a proprietary format is not a good idea and will
 decrease interoperability and negitive dates are not pleasant.  And

We could use signed ints. Also, this is the format used by UNIX, I believe, not something taken randomly.
 Ok, as I am working on a similar project I could use that and convert to

  Of course there will be a lot more to do than just time & date -
 measurement,  decimal points, numbers
         1 000 000 000 .000
         1,000,000,000.000
         1.000.000.000,000       etcetera...
 , currency ($), string compare, case conversion (just knowing what is a
 letter and what is not),  daylight savings,  time zones and probably a few
 other bits and bobs (anything obvious I have missed - by the way I would
 not include boolean translations ie. FALSE -> FALSCH, FAUX, etcetera. -
 they would be better either represented with a symbol [tick / cross] - the

Well maybe better for you. I think this is what locales are for, so we can choose another formats of displaying data, and probably make them ourselves... Is the library as flexible as C++ locale (or even better)? How does its interface look?
Mar 25 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a7nj12$2jad$1 digitaldaemon.com...
 "DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
 news:a7n7d3$2cv1$1 digitaldaemon.com...

 A 64 bit count is a good idea but if we count from 1970 then how do we
 represent dates before then (ie. birthdays - some of which could be as
 early as 1880) - surely a proprietary format is not a good idea and will
 decrease interoperability and negitive dates are not pleasant.  And

We could use signed ints. Also, this is the format used by UNIX, I

 not something taken randomly.

So because Unix got it wrong, we should continue to suffer? :-) I like the Julian cycles idea because it is consistant and doesn't need "negative dates". But it is a small point. One related comment. If we are going to use a 64 bit value for the time, the base should be a unit time much smaller than milliseconds. Microseconds at least, and probably nanoseconds. There should be some minimal accuracy specified (milliseconds is OK for the minimum, with the low order parts set to zero), but we should allow a consistant mechanism for time handling for those systems that support a more precise clock. Since we have to do a divide anyway if we want seconds, having to divide by a larger number isn't a substantial price to pay for the seemlessnes of a single mechanism for high precision timers as well as more mundane uses. -- - Stephen Fuld e-mail address disguised to prevent spam
Mar 25 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a7nr2a$2nes$1 digitaldaemon.com...

 So because Unix got it wrong, we should continue to suffer?  :-) I like

 Julian cycles idea because it is consistant and doesn't need "negative
 dates".   But it is a small point.

You are never going to deal with the internal representation - well, almost. =) Most often you'll use functions like: long makeDate(int day, int month, int year); long dateDiff(long d1, long d2); ...
 One related comment.  If we are going to use a 64 bit value for the time,
 the base should be a unit time much smaller than milliseconds.

 at least, and probably nanoseconds.  There should be some minimal accuracy

64-bit integer is used to store both date and time. Will it be enough to hold large dates with microsecond resolution?
Mar 25 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a7ntlu$2op0$1 digitaldaemon.com...
 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:a7nr2a$2nes$1 digitaldaemon.com...

 So because Unix got it wrong, we should continue to suffer?  :-) I like

 Julian cycles idea because it is consistant and doesn't need "negative
 dates".   But it is a small point.

You are never going to deal with the internal representation - well,

 =)
 Most often you'll use functions like:

     long makeDate(int day, int month, int year);
     long dateDiff(long d1, long d2);
     ...

 One related comment.  If we are going to use a 64 bit value for the


 the base should be a unit time much smaller than milliseconds.

 at least, and probably nanoseconds.  There should be some minimal


 64-bit integer is used to store both date and time. Will it be
 enough to hold large dates with microsecond resolution?

Well, pretty large. If you keep the crecision of microseconds, you are limited to something like 584,000 years. I think that is enough. If you want to go to nanosecond precision, then you are limited to 584 years, which is probably enough in practice (with a base of say 1800 it will last till nearly 2400), but surely someone will object that it isn't sufficient. To avoid that argument, I would be quite willing to accept a precision of microseconds. -- - Stephen Fuld e-mail address disguised to prevent spam
Mar 27 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a7t4d2$2jfd$5 digitaldaemon.com...

 Well, pretty large.  If you keep the crecision of microseconds, you are
 limited to something like 584,000 years.  I think that is enough.  If you
 want to go to nanosecond precision, then you are limited to 584 years,

 is probably enough in practice (with a base of say 1800 it will last till
 nearly 2400), but surely someone will object that it isn't sufficient.

 To avoid that argument, I would be quite willing to accept a precision of
 microseconds.

Agreed. I don't know why somebody would want to measure dates with nanosecond precision. Nanoseconds are used in timers, but you most likely aren't going to have your program run for more than 500 years =)
Mar 27 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a7tdid$2o6t$1 digitaldaemon.com...
 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:a7t4d2$2jfd$5 digitaldaemon.com...

 Well, pretty large.  If you keep the crecision of microseconds, you are
 limited to something like 584,000 years.  I think that is enough.  If


 want to go to nanosecond precision, then you are limited to 584 years,

 is probably enough in practice (with a base of say 1800 it will last


 nearly 2400), but surely someone will object that it isn't sufficient.

 To avoid that argument, I would be quite willing to accept a precision


 microseconds.

Agreed. I don't know why somebody would want to measure dates with nanosecond precision. Nanoseconds are used in timers, but you most likely aren't

 to have your program run for more than 500 years =)

True, of course, but people might want to measure elapsed time in nanoseconds or time some precision event in nanoseconds (remember in a few years, 1 nanosecond will be something like 10 instructions on a then current CPU) and, in your other post, you objected to having date and time be separate variables because you couldn't handle time differences across midnight by a simple subtraction, etc. -- - Stephen Fuld e-mail address disguised to prevent spam
Mar 27 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a7tm70$2sjd$1 digitaldaemon.com...

 True, of course, but people might want to measure elapsed time in
 nanoseconds or time some precision event in nanoseconds (remember in a few
 years, 1 nanosecond will be something like 10 instructions on a then

 CPU) and, in your other post, you objected to having date and time be
 separate variables because you couldn't handle time differences across
 midnight by a simple subtraction, etc.

You don't need a date variable to measure elapsed time - a simple ulong counter will do, and you can use arbitrary precision there, nanoseconds or whatever else... dates and timers are two different things, why mix them?
Mar 27 2002
parent reply Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:
 You don't need a date variable to measure elapsed time - a simple
 ulong counter will do, and you can use arbitrary precision there,
 nanoseconds or whatever else... dates and timers are two different
 things, why mix them?

Time is time, why make a distinction? If it meant that I had to remember one time API instead of two, I'd be willing to spend an extra 64 bits per time object in order to unify high-precision and high-range time. <here he goes again> Given operator overloading, the 128-bit time class could look like a first-class datatype, as well. </here he goes again> That said, two APIs isn't so much of a problem, and some people might well want to save the space, so I'm okay either way. -RB
Mar 28 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3CA364D3.2010105 estarcion.com...
 Pavel Minayev wrote:
 You don't need a date variable to measure elapsed time - a simple
 ulong counter will do, and you can use arbitrary precision there,
 nanoseconds or whatever else... dates and timers are two different
 things, why mix them?

Time is time, why make a distinction? If it meant that I had to remember one time API instead of two, I'd be willing to spend an extra 64 bits per time object in order to unify high-precision and high-range time.

Yes. Why do you (Pavel) think dates and timers are different things? Let me give an example. For a health insurance program, you might want to calculate the length of someones's stay in the hospital (in days). This requires essentially subtracting the release date from the entry date and adding one day. How is this a totally different thing from getting the duration of some program loop by subtracting the start time from the completion time? Having "timers" and absolute date/time retrieval use the same interface simplifies things. One fewer thing to learn. That is the primary motivation for combining them. As for taking up more space, I believe Walter was proposing using a single 64 bit quantity, which is what I agreed was the best solution. The only difference was I proposed adding the bits for higher precision, which costs nothing (except some totally beyond the fringe date ranges) by essentially shifting the field left. There was a quibble about the base starting date, but we agreed that was a quibble. -- - Stephen Fuld e-mail address disguised to prevent spam
Mar 28 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a7vtfk$10i4$1 digitaldaemon.com...

 Yes.  Why do you (Pavel) think dates and timers are different things?  Let

They aren't
 me give an example.  For a health insurance program, you might want to
 calculate the length of someones's stay in the hospital (in days).  This
 requires essentially subtracting the release date from the entry date and
 adding one day.  How is this a totally different thing from getting the
 duration of some program loop by subtracting the start time from the
 completion time?

Yep. Both will be uints. Only for program, you might want it to run with nanosecond precision, while date would be measured in microseconds. But you still find the delta with operator-. Dates are different in a sense they denote some concrete moment. Date can be converted to some human-readable format. On other hand, timers are used to measure time elapsed from some arbitrary moment that you define, so for example the dayOfWeek() function would make sence on dates but not on timers. Timer is just a raw counter, and thus one could use uint without any typedefs (what functions would you expect to work with timers?). Date, however, would be a typedef, so it could be overloaded separately.
 As for taking up more space, I believe Walter was proposing using a single
 64 bit quantity, which is what I agreed was the best solution.  The only
 difference was I proposed adding the bits for higher precision, which

So what is the suggested precision? Nanoseconds? Or microseconds?
Mar 28 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a800hs$12dg$1 digitaldaemon.com...
 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:a7vtfk$10i4$1 digitaldaemon.com...

 Yes.  Why do you (Pavel) think dates and timers are different things?


 They aren't

 me give an example.  For a health insurance program, you might want to
 calculate the length of someones's stay in the hospital (in days).  This
 requires essentially subtracting the release date from the entry date


 adding one day.  How is this a totally different thing from getting the
 duration of some program loop by subtracting the start time from the
 completion time?

Yep. Both will be uints. Only for program, you might want it to run with nanosecond precision, while date would be measured in microseconds. But you still find the delta with operator-. Dates are different in a sense they denote some concrete moment. Date can be converted to some human-readable format. On other hand, timers are used to measure time elapsed from some arbitrary moment that you define, so for example the dayOfWeek() function would make sence on dates but not on timers. Timer is just a raw counter, and thus one could use uint without any typedefs (what functions would you expect to work with timers?). Date, however, would be a typedef, so it could be overloaded separately.
 As for taking up more space, I believe Walter was proposing using a


 64 bit quantity, which is what I agreed was the best solution.  The only
 difference was I proposed adding the bits for higher precision, which

So what is the suggested precision? Nanoseconds? Or microseconds?

If you are willing to live with a range of about 580 years, then nanoseconds. However, there are a number of people who feel that is insufficient (I think it is OK, but I can see their point), in which case microseconds precision with a range of 580,000 years is still a better solution than what Walter originally proposed (millisecond resolution) and is probably the best compromise. The extra precision you get by going from milliseconds to microseconds is essentially free if you use a 64 bit int for the value. If, as some prefer, but a separate question, we kept time in a separate 64 bit value from date, then nanosecond precision (and even more precise, but that seems to be to be guilding the lilly) is free and thus should IMHO be adopted. -- - Stephen Fuld e-mail address disguised to prevent spam
Mar 28 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a811ku$1jut$1 digitaldaemon.com...

 If you are willing to live with a range of about 580 years, then
 nanoseconds.  However, there are a number of people who feel that is
 insufficient (I think it is OK, but I can see their point), in which case
 microseconds precision with a range of 580,000 years is still a better
 solution than what Walter originally proposed (millisecond resolution) and
 is probably the best compromise.

I agree. Microsecond precision gives wide range of dates, and is enough for most practical timing purposes.
Mar 29 2002
prev sibling next sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
Stephen Fuld wrote:
 So because Unix got it wrong, we should continue to suffer?  :-) I like the
 Julian cycles idea because it is consistant and doesn't need "negative
 dates".   But it is a small point.

4713 BCE isn't the beginning of time. You _will_ need negative dates. Or rather, someone will -- albeit not necessarily with high precision.
 One related comment.  If we are going to use a 64 bit value for the time,
 the base should be a unit time much smaller than milliseconds.  Microseconds
 at least, and probably nanoseconds. 

64 bits isn't quite enough to specify billions of years with billionths of seconds precision. It's probably enough to handle almost every need, but I'm inclined to use: int64 signed_seconds_since_epoch; uint64 unsigned_fractional_seconds; Or, looked at another way, a signed 64.64 fixed- point, with the point at the seconds place. I don't really care if Epoch is noon/1/1/4713BCE or midnight/1/1/1970 or 10:23am/8/23/1969. Whatever's convenient for one bunch of people (astronomers, accountants, physicists, historians) will be inconvenient for another bunch, but all you need to know is what to add/subtract to convert. -RB
Mar 25 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C9F8E94.8030001 estarcion.com...

 64 bits isn't quite enough to specify billions of
 years with billionths of seconds precision. It's
 probably enough to handle almost every need, but
 I'm inclined to use:

 int64
 signed_seconds_since_epoch;
 uint64          unsigned_fractional_seconds;

A single uint is enough to hold any date in approximate range of 0-500000 years with microsecond precision. I guess it's pretty enough for any exact date; yes, sometimes they say "it was in year 30,000,000 BC", but it's not a date, it's just a year. So, for any practical purpose, I guess this method fits. What will be the zero-point is not so important - as you've stated, it's just the matter of adding/subtracting some constant value...
Mar 25 2002
parent reply Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:
 A single uint is enough to hold any date in approximate range of 0-500000
 years with microsecond precision. I guess it's pretty enough for any
 exact date; yes, sometimes they say "it was in year 30,000,000 BC", but
 it's not a date, it's just a year. 

My point is that some people need bigger range, and other people need more precision. If you want a single time type in the language, it needs to cover both those needs, otherwise someone is going to say "microseconds? bah! I need nanoseconds!" or "millions of years? bah! I need billions!", and 64 bits might not be enough. -R
Mar 25 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C9FA0E2.4080000 estarcion.com...
 Pavel Minayev wrote:
 A single uint is enough to hold any date in approximate range of


 years with microsecond precision. I guess it's pretty enough for any
 exact date; yes, sometimes they say "it was in year 30,000,000 BC", but
 it's not a date, it's just a year.

My point is that some people need bigger range, and other people need more precision. If you want a single time type in the language, it needs to cover both those needs, otherwise someone is going to say "microseconds? bah! I need nanoseconds!" or "millions of years? bah! I need billions!", and 64 bits might not be enough.

A 64 bit signed int measured in milliseconds will handle time for +- 285,000 years. That's enough for system programming use. I agree it will likely not be adequate for astronomers, but there should be no trouble adding a package that has time measured in astronomical units. 64 bit ints are nice because they are conveniently handled by the compiler. Sometimes I need microsecond times - but for computing elapsed time for things like profiling, not for measuring calendar time. I think those are handled adequately by being separate. In any case, it will be a typedef, and if the API for it is followed, there should be no trouble if someone upgrades to a 128 bit time or whatever.
Mar 25 2002
prev sibling parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C9FA0E2.4080000 estarcion.com...
 Pavel Minayev wrote:
 A single uint is enough to hold any date in approximate range of


 years with microsecond precision. I guess it's pretty enough for any
 exact date; yes, sometimes they say "it was in year 30,000,000 BC", but
 it's not a date, it's just a year.

My point is that some people need bigger range, and other people need more precision. If you want a single time type in the language, it needs to cover both those needs, otherwise someone is going to say "microseconds? bah! I need nanoseconds!" or "millions of years? bah! I need billions!", and 64 bits might not be enough.

Note that the original poster suggested two 64 bit values, one for days and one for time of day . Using this idea, we have plenty of bits for time accurate to nanoseconds, (or even less) and dates even if you set the start date to something like the big bang. :-) -- - Stephen Fuld e-mail address disguised to prevent spam
Mar 27 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a7t4db$2jfd$6 digitaldaemon.com...

 Note that the original poster suggested two 64 bit values, one for days

 one for time of day .  Using this idea, we have plenty of bits for time
 accurate to nanoseconds, (or even less) and dates even if you set the

 date to something like the big bang.  :-)

However, this requires twice more memory, and you can't just subtract one value from another, or compare dates, etc.
Mar 27 2002
parent reply DrWhat? <blackmarlin nospam.asean-mail.com> writes:
Pavel Minayev wrote:

 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:a7t4db$2jfd$6 digitaldaemon.com...
 
 Note that the original poster suggested two 64 bit values, one for days

 one for time of day .  Using this idea, we have plenty of bits for time
 accurate to nanoseconds, (or even less) and dates even if you set the

 date to something like the big bang.  :-)

However, this requires twice more memory, and you can't just subtract one value from another, or compare dates, etc.

would be be more efficient and nearly as effective. I expect the date and time values to be used for time stamps on file systems etc, not for nano second precision - that is the job of specialist timers (and besides the overhead of a call to the date/time routines could easily mess up a nano second count, rendering its output effectively worthless). The problem with storing date and time in a single 64 bit value is that leap _seconds_ are added (and subtracted) in an arbitrary way to compensate for planetary deceleration (ok, it is not truly arbitrary but for our results it may as well be). Do you really want programmes written in D to be a few minutes out compared to real time? After all the purpose of a standard date/time library is to prevent such problems (even with people using different date and time representations) by using a standard format which is easily convertable. Finally the date and time, if stored in separate 32 bit uints, could be split up - if you want to know, for example, the date of a birthday the time is commonly unimportant. And if creating an alarm clock the date is similarly unwanted. Although addition and subtraction of dates in this format is not as trivial, comparasons are just as simple. (add/sub -> time+=newTime; date+=newDate+time/secondsInDay; time%=secondsInDay; is that really that much more difficult - these operations could easily be added to the time/date library) ` newTime <- eax ` 586 timings (Intel) ` newDate <- ebx add eax, time ` 1 U xor edx, edx ` V `cwde ` could be used - but c = 3 NP div secondsInDay ` 41 NP (ouch) add ebx, eax ` 1 U mov time, edx ` V add date, ebx ` 1 U `== 44 total (&free slot [pop ebp?]) ` ( time for 64 bit add is 4 cycles ) ` ( nb: I think divides are faster on newer processors, and they take ` less cycles on older processors (38-386,40-486) ) C 2002/3/28
Mar 28 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
news:a7v0f9$ger$1 digitaldaemon.com...
 Pavel Minayev wrote:

 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:a7t4db$2jfd$6 digitaldaemon.com...

 Note that the original poster suggested two 64 bit values, one for days

 one for time of day .  Using this idea, we have plenty of bits for time
 accurate to nanoseconds, (or even less) and dates even if you set the

 date to something like the big bang.  :-)

However, this requires twice more memory, and you can't just subtract


 value from another, or compare dates, etc.

would be be more efficient and nearly as effective. I expect the date and time values to be used for time stamps on file systems etc, not for nano second precision - that is the job of specialist timers (and besides the overhead of a call to the date/time routines could easily mess up a nano second count, rendering its output effectively worthless). The problem with storing date and time in a single 64 bit value is that leap _seconds_ are added (and subtracted) in an arbitrary way to

 for planetary deceleration (ok,  it is not truly arbitrary but for our
 results it may as well be).  Do you really want programmes written in D to
 be a few minutes out compared to real time?  After all the purpose of a
 standard date/time library is to prevent such problems (even with people
 using different date and time representations) by using a standard format
 which is easily convertable.

 Finally the date and time, if stored in separate 32 bit uints, could be
 split up - if you want to know, for example, the date of a birthday the
 time is commonly unimportant.  And if creating an alarm clock the date is
 similarly unwanted.  Although addition and subtraction of dates in this
 format is not as trivial,  comparasons are just as simple.
 (add/sub -> time+=newTime; date+=newDate+time/secondsInDay;
 time%=secondsInDay;  is that really that much more difficult - these
 operations could easily be added to the time/date library)

         `       newTime <- eax          ` 586 timings (Intel)
         `       newDate <- ebx
         add     eax, time               ` 1     U
         xor     edx, edx                `       V
         `cwde   ` could be used - but c = 3 NP
         div     secondsInDay            ` 41    NP      (ouch)
         add     ebx, eax                ` 1     U
         mov     time, edx               `       V
         add     date, ebx               ` 1     U
                                         `== 44 total (&free slot [pop

         ` ( time for 64 bit add is 4 cycles )
         ` ( nb: I think divides are faster on newer processors,  and they

         `   less cycles on older processors (38-386,40-486) )

 C       2002/3/28

So use an OLE DATE compatible format, 64 bits float. This way splitting date and time is very easy, you don't need to invent difficult routines (MFC COleDateTime and Delphi TDateTime routines are open- source and all the problems you mention have been solved by other people before. Also, you get instantly free compatibility with OLE. See my other post... -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Mar 28 2002
prev sibling parent "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a7nr2a$2nes$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a7nj12$2jad$1 digitaldaemon.com...
 "DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
 news:a7n7d3$2cv1$1 digitaldaemon.com...

 A 64 bit count is a good idea but if we count from 1970 then how do we
 represent dates before then (ie. birthdays - some of which could be as
 early as 1880) - surely a proprietary format is not a good idea and



 decrease interoperability and negitive dates are not pleasant.  And

We could use signed ints. Also, this is the format used by UNIX, I

 not something taken randomly.

So because Unix got it wrong, we should continue to suffer? :-) I like

 Julian cycles idea because it is consistant and doesn't need "negative
 dates".   But it is a small point.

 One related comment.  If we are going to use a 64 bit value for the time,
 the base should be a unit time much smaller than milliseconds.

 at least, and probably nanoseconds.  There should be some minimal accuracy
 specified (milliseconds is OK for the minimum, with the low order parts

 to zero), but we should allow a consistant mechanism for time handling for
 those systems that support a more precise clock.  Since we have to do a
 divide anyway if we want seconds, having to divide by a larger number

 a substantial price to pay for the seemlessnes of a single mechanism for
 high precision timers as well as more mundane uses.

 --
  - Stephen Fuld
    e-mail address disguised to prevent spam

Mar 27 2002
prev sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"DrWhat?" <DrWhat nospam.madscientist.co.uk> wrote in message
news:a7koqi$20lc$1 digitaldaemon.com...
<SNIP>
 A little info (copied from somewhere on the Internet many years ago -

 lost the URL and it probably no longer exists anyway)

 ---------------------

Guess what, it still exists... You can't beat google :) http://www.faqs.org/faqs/astronomy/faq/part3/section-6.html http://www.geocities.com/CapeCanaveral/Lab/7671/julian.htm I like your idea by the way! Has someone looked at OleDateTime? I believe it's a 64 bit float? It represents the amount of days passed since some moment in time. Parts of a day are represented with the fractional part of the float, so 6 hours would translate to the number 0.25, 12 hours to 0.5, two days to 2.0 and 3 days and 18 hours to 3.75. The advantage of this system is that it is very easy to extract either the date or the time part of a datetime. Also, calculations with precision in days do not need to divide the number. D's more advanced version could use an extended. I don't know what kind of range and precision that would give, but I bet it's enormeous! -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Mar 25 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a7obqv$30n9$1 digitaldaemon.com...
 "DrWhat?" <DrWhat nospam.madscientist.co.uk> wrote in message
 news:a7koqi$20lc$1 digitaldaemon.com...
 <SNIP>
 A little info (copied from somewhere on the Internet many years ago -

 lost the URL and it probably no longer exists anyway)

 ---------------------

Guess what, it still exists... You can't beat google :) http://www.faqs.org/faqs/astronomy/faq/part3/section-6.html http://www.geocities.com/CapeCanaveral/Lab/7671/julian.htm I like your idea by the way! Has someone looked at OleDateTime? I believe it's a 64 bit float? It represents the amount of days passed since some moment in time. Parts of a day are represented with the fractional part of the float, so 6 hours would translate to the number 0.25, 12 hours to 0.5, two days to 2.0 and 3 days and 18 hours to 3.75. The advantage of this system is that it is very easy to extract either the date or the time part of a datetime. Also, calculations with precision in days do not need to divide the number. D's more advanced version could use an extended. I don't know what kind of range and precision that would give, but I bet it's enormeous! -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail

So, how about it? An extended for a datetime?
Mar 27 2002
parent reply DrWhat? <blackmarlin nospam.asean-mail.com> writes:
 
 So, how about it? An extended for a datetime?
 

1 converting time -> seconds is none trivial 2 not all computers have extended precision floats (some do not even have double precision) (Though the dates and up looking like Treky stardates - which should appeal to geeks :-)
Mar 28 2002
next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
news:a7uu46$epg$1 digitaldaemon.com...
 So, how about it? An extended for a datetime?

1 converting time -> seconds is none trivial

alias DateTime extended; DateTime dt = 3.25; DateTime date = (long) dt; DateTime time = dt - date; // time is a fraction of a day. // 1 Day == 24 hours, so mul. time by 24 to get hours... DateTime hours = time * 24; // 1 Day == 1440 minutes, so mul. time by 1440 to get min... DateTime min = time * 1440; // 1 Day == 86400 seconds, so mul. time by 86400 to get sec... DateTime sec = time * 86400; Ofcourse you could go on for milliseconds, microseconde, nanoseconds etc... To me it seems quitte trivial, or am I missing something important? Also, this format is used by Ole DATE and the MFC COleDateTime and Delphi TDateTime classes, both of which come with source, so getting all the other algorithms should be easy.
         2       not all computers have extended precision floats
                 (some do not even have double precision)

OK, Fair enough... So, buy a new computer! Sounds very bulish, I admit, but some processors don't have 32-bit addressing either, but it didn't stop Walter from making that the lowest supported format for D. And fully justified too I think. We have to look for the future, not always back at the past... How about this: If there are common 32-bit processors that do not support 80-bit extended, go for 64 bit double instead. If they all support it, use 80 bit, we want precision, not speed, because most 3D graphics do not need dates! :) Conversion to and from double to extended is easy anyway as long as you stay within the safe range. When you go out of range you have just proven that we actually *need* 80 bits!
 (Though the dates and up looking like Treky stardates - which should

 to geeks :-)

LOL! You got me, that's why I like it! :) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Mar 28 2002
parent reply DrWhat? <blackmarlin nospam.asean-mail.com> writes:
OddesE wrote:

 "DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
 news:a7uu46$epg$1 digitaldaemon.com...
 So, how about it? An extended for a datetime?

1 converting time -> seconds is none trivial

alias DateTime extended; DateTime dt = 3.25; DateTime date = (long) dt; DateTime time = dt - date;

(need a multiply here, then another conversion to convert to seconds before we can even think of converting it into a national standard). total - 3 conversions, 1 subtract, 1 multiply. That is going to take even more processor cycles that my solution, and may have some problems in terms of precision. Also why use the FPU when there is no need, especially when it is less efficient. But that is not the real problem.
 // time is a fraction of a day.
 // 1 Day == 24 hours, so mul. time by 24 to get hours...
 DateTime hours = time * 24;
 
 // 1 Day == 1440 minutes, so mul. time by 1440 to get min...
 DateTime min = time * 1440;
 
 // 1 Day == 86400 seconds, so mul. time by 86400 to get sec...
 DateTime sec = time * 86400;

Wrong - 1 Day may equal 86399 or 86401 seconds - remember leap seconds, they are a problem when converting dates into seconds, and that is the problem I am trying to avoid.
 Ofcourse you could go on for milliseconds, microseconde,
 nanoseconds etc... To me it seems quitte trivial, or am
 I missing something important?
 
 Also, this format is used by Ole DATE and the MFC
 COleDateTime and Delphi TDateTime classes, both of
 which come with source, so getting all the other
 algorithms should be easy.

I do not programme or even use Windows, I could not comment on this.
         2       not all computers have extended precision floats
                 (some do not even have double precision)

OK, Fair enough... So, buy a new computer! Sounds very bulish, I admit, but some processors don't have 32-bit addressing either, but it didn't stop Walter from making that the lowest supported format for D. And fully justified too I think. We have to look for the future, not always back at the past...

I think a flat memory model is necessary for D not necessarily 32 bit addressing - this would rule out the 8086 but still allow porting to ie. the Z80 or similar embedded system CPUs with a 16 bit flat memory model.
 How about this: If there are common 32-bit processors
 that do not support 80-bit extended, go for 64 bit
 double instead. If they all support it, use 80 bit, we
 want precision, not speed, because most 3D graphics
 do not need dates! :)
 
 Conversion to and from double to extended is easy
 anyway as long as you stay within the safe range.
 When you go out of range you have just proven that
 we actually *need* 80 bits!

This attitude is what will make D a Intel / Windows only programming language - if D is going to be truely sucessful it must be able to support the majority of architectures. Few processors support 80 bit extended precision floating point numbers, and many (ie. RISC processors) do not even have a floating point capibility and emulate it using integer instructions if required. Using a floating point format (especially the rubbish one that is IEEE 754) would only decrease the ease of porting which would lead to D being a wide spread langauge.
 (Though the dates and up looking like Treky stardates - which should
 appeal to geeks :-)

LOL! You got me, that's why I like it! :)

I guess me being a B5 fan is why I do not :-) The year is 2259 ... but how the %^&* are we going to represent it. C 2002/3/28
Mar 28 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
news:a7vmt7$t7i$1 digitaldaemon.com...

 (Though the dates and up looking like Treky stardates - which should
 appeal to geeks :-)

LOL! You got me, that's why I like it! :)

I guess me being a B5 fan is why I do not :-)

I second that, being a B5 fan myself. I guess ulong is just enough.
 The year is 2259 ... but how the %^&* are we going to represent it.

Nah, it's 2262! =)
Mar 28 2002
prev sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
news:a7vmt7$t7i$1 digitaldaemon.com...
 OddesE wrote:

 "DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
 news:a7uu46$epg$1 digitaldaemon.com...
 So, how about it? An extended for a datetime?

1 converting time -> seconds is none trivial

alias DateTime extended; DateTime dt = 3.25; DateTime date = (long) dt; DateTime time = dt - date;

(need a multiply here, then another conversion to convert to seconds before we can even think of converting it into a national standard). total - 3 conversions, 1 subtract, 1 multiply.

Where do we need the multiply? DateTime dt = 3.25; DateTime date = (long) dt; // This should truncate dt into date, yielding 3.0; DateTime time = dt - date; // 3.25 - 3.0 = 0.25 // Represents 06:00u We only need a multiply if we want to convert to hours, minutes or seconds is it not? If we use a longint, won't we need a divide? Aren't divides more expensive than multiplies? I am not claiming any of these things to be true, I am really just asking, because this is what I thought it was. Also, why did Borland and MS both picked a 64 bit float if it would be that bad? - Getting the date is a truncating assignment. - Getting the time is a truncating assignment and a subtract. - Getting both is a truncating assignment, a subtract and another assignment. - Getting hours, seconds, minutes etc is a truncating assignment, a subtract and a multiply...That is not too expensive is it?
 That is going to take even more processor cycles that my solution,  and

 have some problems in terms of precision.  Also why use the FPU when there
 is no need,  especially when it is less efficient.  But that is not the
 real problem.

How are you going to avoid floating point operations if you use a longint to represent elapsed microseconds? Won't you need to divide to get seconds, minutes, hours etc? I thought FPU operations were fast becoming as cheap as fp-emulation operations?
 // time is a fraction of a day.
 // 1 Day == 24 hours, so mul. time by 24 to get hours...
 DateTime hours = time * 24;

 // 1 Day == 1440 minutes, so mul. time by 1440 to get min...
 DateTime min = time * 1440;

 // 1 Day == 86400 seconds, so mul. time by 86400 to get sec...
 DateTime sec = time * 86400;

Wrong - 1 Day may equal 86399 or 86401 seconds - remember leap seconds, they are a problem when converting dates into seconds, and that is the problem I am trying to avoid.

You are right here...Then again, 1 day might be 23, 24 or 25 hours depending on daylight saving time and one year might be 365 or 366 days depending on the leapyear. If you have a solution that solves this, great! I just reread the Julian cycle story, but isn't it also counting days from a certain starting point? If you are proposing to keep date and time separate, then that might be a solution, but what is the real advantage of that? Usually when I use dates in my program I want to do things like compare them and add or subtract them. These operations benefit greatly from a format with date and time stuffed together. It isn't all that much I want to actually display them, and that is the only moment when it really matters that there are leapyears, -hours and -seconds. A conversion will do just fine then, and who cares if it is slow, displaying information tends to be slow anyhow. Also, when you think about it, what is the difference between a date and a time? Isn't a date just time measured in days, while time is time measured in parts of days?
 Ofcourse you could go on for milliseconds, microseconde,
 nanoseconds etc... To me it seems quitte trivial, or am
 I missing something important?

 Also, this format is used by Ole DATE and the MFC
 COleDateTime and Delphi TDateTime classes, both of
 which come with source, so getting all the other
 algorithms should be easy.

I do not programme or even use Windows, I could not comment on this.

Ah come on...This has got nothing to do with windows. Open source is open source and algorithms are algorithms, no matter on what system you are. I agree that MS achieved 'polluting' C with WinMain et al, but you should still be able to read it... ;)
         2       not all computers have extended precision floats
                 (some do not even have double precision)

OK, Fair enough... So, buy a new computer! Sounds very bulish, I admit, but some processors don't have 32-bit addressing either, but it didn't stop Walter from making that the lowest supported format for D. And fully justified too I think. We have to look for the future, not always back at the past...

I think a flat memory model is necessary for D not necessarily 32 bit addressing - this would rule out the 8086 but still allow porting to ie. the Z80 or similar embedded system CPUs with a 16 bit flat memory model.

You are probably right...
 How about this: If there are common 32-bit processors
 that do not support 80-bit extended, go for 64 bit
 double instead. If they all support it, use 80 bit, we
 want precision, not speed, because most 3D graphics
 do not need dates! :)

 Conversion to and from double to extended is easy
 anyway as long as you stay within the safe range.
 When you go out of range you have just proven that
 we actually *need* 80 bits!

This attitude is what will make D a Intel / Windows only programming language - if D is going to be truely sucessful it must be able to support the majority of architectures. Few processors support 80 bit extended precision floating point numbers, and many (ie. RISC processors) do not even have a floating point capibility and emulate it using integer instructions if required. Using a floating point format (especially the rubbish one that is IEEE 754) would only decrease the ease of porting

 would lead to D being a wide spread langauge.

I do not understand... Are these systems not capable of handling a double or extended? If they do, what is the difference with a date? I think my attitude has got nothing to do with Windows or Intel, but with old and new. I understand the need to support old hardware up to a point, but in such a young language as D is, I'd rather look forward and make sure we are forwards compatible with the future. If 64-bit's float is too much to ask for too many systems, that's it, you won't hear me about it again, but I just find it hard to believe that there are that many systems out there that do not support it. Could you name some examples?
 (Though the dates and up looking like Treky stardates - which should
 appeal to geeks :-)

LOL! You got me, that's why I like it! :)

I guess me being a B5 fan is why I do not :-) The year is 2259 ... but how the %^&* are we going to represent it. C 2002/3/28

Whatever the format, *please* make it big! (So we can still use it in 2259 when people live to be a thousand years old!) :) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Mar 28 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a7vvc1$11or$1 digitaldaemon.com...
 "DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
 news:a7vmt7$t7i$1 digitaldaemon.com...
 OddesE wrote:

 "DrWhat?" <blackmarlin nospam.asean-mail.com> wrote in message
 news:a7uu46$epg$1 digitaldaemon.com...
 So, how about it? An extended for a datetime?

1 converting time -> seconds is none trivial

alias DateTime extended; DateTime dt = 3.25; DateTime date = (long) dt; DateTime time = dt - date;

(need a multiply here, then another conversion to convert to seconds before we can even think of converting it into a national standard). total - 3 conversions, 1 subtract, 1 multiply.

Where do we need the multiply? DateTime dt = 3.25; DateTime date = (long) dt; // This should truncate dt into date, yielding 3.0; DateTime time = dt - date; // 3.25 - 3.0 = 0.25 // Represents 06:00u We only need a multiply if we want to convert to hours, minutes or seconds is it not? If we use a longint, won't we need a divide? Aren't divides more expensive than multiplies? I am not claiming any of these things to be true, I am really just asking, because this is what I thought it was. Also, why did Borland and MS both picked a 64 bit float if it would be that bad?

Because they were not at all concerned with being able to run on systems that didn't have floating point support. If D is successfull, it will get used in a lot of embedded applications where floating point support in hardware just isn't there. We should not lightly write off these types of systems for a small benefit.
 - Getting the date is a truncating assignment.
 - Getting the time is a truncating assignment and a subtract.
 - Getting both is a truncating assignment, a subtract and
   another assignment.
 - Getting hours, seconds, minutes etc is a truncating assignment,
   a subtract and a multiply...That is not too expensive is it?


 That is going to take even more processor cycles that my solution,  and

 have some problems in terms of precision.  Also why use the FPU when


 is no need,  especially when it is less efficient.  But that is not the
 real problem.

How are you going to avoid floating point operations if you use a longint to represent elapsed microseconds? Won't you need to divide to get seconds, minutes, hours etc?

You have to do a divide, but not a floating point divide. Many CPUs support integer divide instructions, or at least hardware assist for divide instructions.
 I thought FPU operations were fast becoming as cheap as
 fp-emulation operations?

No. And again, many embedded systems have no need for floating point at all. They would be reluctant to include a floating point emulation package just to be able to handle dates and times. Just to remind people, the number of CPUs sold for embedded applications *far* exceeds the number sold for desktop and server applications. -- - Stephen Fuld e-mail address disguised to prevent spam
Mar 28 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a811kv$1jut$2 digitaldaemon.com...
 No.  And again, many embedded systems have no need for floating point at
 all.  They would be reluctant to include a floating point emulation

 just to be able to handle dates and times.
 Just to remind people, the number of CPUs sold for embedded applications
 *far* exceeds the number sold for desktop and server applications.

I think by using careful typedef's for the time, whether it is a 64 bit int or a 128 bit int or milliseconds or microseconds, etc., will be an implementation issue. The programmer will just use the typedef's and the api's for it, and it should not be relevant to him what the underlying representation is. I know about the ole floating point date format, but I can't see any superiority in using floats for time. I just see losing precision as the exponent bits take away from the precision. Conversions from 64 bit int time to 64 bit float time is trivial, anyway, it's just a divide and an add.
Mar 29 2002
next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a826te$69l$1 digitaldaemon.com...
 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:a811kv$1jut$2 digitaldaemon.com...
 No.  And again, many embedded systems have no need for floating point at
 all.  They would be reluctant to include a floating point emulation

 just to be able to handle dates and times.
 Just to remind people, the number of CPUs sold for embedded applications
 *far* exceeds the number sold for desktop and server applications.

I think by using careful typedef's for the time, whether it is a 64 bit

 or a 128 bit int or milliseconds or microseconds, etc., will be an
 implementation issue. The programmer will just use the typedef's and the
 api's for it, and it should not be relevant to him what the underlying
 representation is.

 I know about the ole floating point date format, but I can't see any
 superiority in using floats for time. I just see losing precision as the
 exponent bits take away from the precision. Conversions from 64 bit int

 to 64 bit float time is trivial, anyway, it's just a divide and an add.

OK, You've all convinced me, and I am outnumbered anyhow :) Can anyone point me to a location where I can get some specs on datetime formats, because I would like to try writing a datetime module... -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Mar 29 2002
parent "Walter" <walter digitalmars.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a829dg$qva$1 digitaldaemon.com...
 OK, You've all convinced me, and I am outnumbered anyhow :)
 Can anyone point me to a location where I can get some specs
 on datetime formats, because I would like to try writing
 a datetime module...

I posted the OLE format in another post in this thread. Found it on google <g>.
Mar 29 2002
prev sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a826te$69l$1 digitaldaemon.com...

 I think by using careful typedef's for the time, whether it is a 64 bit

 or a 128 bit int or milliseconds or microseconds, etc., will be an
 implementation issue. The programmer will just use the typedef's and the
 api's for it, and it should not be relevant to him what the underlying
 representation is.

Is it a good idea? I mean, when you do (a - b), you don't know whether the result is in milli-, micro-, or nanoseconds... probably it is better to fix measuring units, but vary size - int64, int128 etc.
Mar 29 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a82foe$2ked$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a826te$69l$1 digitaldaemon.com...
 I think by using careful typedef's for the time, whether it is a 64 bit

 or a 128 bit int or milliseconds or microseconds, etc., will be an
 implementation issue. The programmer will just use the typedef's and the
 api's for it, and it should not be relevant to him what the underlying
 representation is.

the result is in milli-, micro-, or nanoseconds... probably it is better to fix measuring units, but vary size - int64, int128 etc.

You have a constant like CLOCKS_PER_SECOND.
Mar 29 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a82km3$2m2l$1 digitaldaemon.com...

 Is it a good idea? I mean, when you do (a - b), you don't know whether
 the result is in milli-, micro-, or nanoseconds... probably it is
 better to fix measuring units, but vary size - int64, int128 etc.

You have a constant like CLOCKS_PER_SECOND.

So, (a - b) / CLOCKS_PER_SECOND? But this means additional division, which is not that good in time-critical situations (where timers are used frequently). Hm, and what's the problem with fixed units? Microseconds seem to be enough for most purposes, WHY would somebody decide to use something else in his implementation? Isn't it just better to standartize it?
Mar 29 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a82n5c$nqn$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a82km3$2m2l$1 digitaldaemon.com...
 Is it a good idea? I mean, when you do (a - b), you don't know whether
 the result is in milli-, micro-, or nanoseconds... probably it is
 better to fix measuring units, but vary size - int64, int128 etc.


which is not that good in time-critical situations (where timers are used frequently).

The divide is only necessary when doing the report, which is not performance critical. (I've written profilers using the cycle timer instruction on the Pentium.)
 Hm, and what's the problem with fixed units? Microseconds seem
 to be enough for most purposes, WHY would somebody decide
 to use something else in his implementation? Isn't it just better
 to standartize it?

That's what people did years ago when unix time was in seconds. It worked for a couple decades, then there was all the falderol because it needed to change <g>.
Mar 29 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a82rr9$2e3f$1 digitaldaemon.com...

 The divide is only necessary when doing the report, which is not

 critical. (I've written profilers using the cycle timer instruction on the
 Pentium.)

Not really. Suppose I want something to happen in one mcs after: time t = clock(); ... if ((clock() - t) / CLOCKS_PER_SEC / 1000000 >= 1) // do it
 That's what people did years ago when unix time was in seconds. It worked
 for a couple decades, then there was all the falderol because it needed to
 change <g>.

Then, use two longs, and nanosecond precision. THIS is going to be enough just for everybody.
Mar 29 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a83g0b$1slr$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a82rr9$2e3f$1 digitaldaemon.com...
 The divide is only necessary when doing the report, which is not

 critical. (I've written profilers using the cycle timer instruction on


 Pentium.)

time t = clock(); ... if ((clock() - t) / CLOCKS_PER_SEC / 1000000 >= 1) // do it

Try this for, say, a delay of 1 hundreth of a second: if ((clock() - t) >= CLOCKS_PER_SEC / 100) The division is done at compile time.
Mar 29 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a83kjb$1vtr$2 digitaldaemon.com...

 Try this for, say, a delay of 1 hundreth of a second:
     if ((clock() - t) >= CLOCKS_PER_SEC / 100)

 The division is done at compile time.

Okay, you've catched me =) But... not so fast! I don't like the name of the constant! =) Probably something like TicksPerSecond would be better?
Mar 30 2002
parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a849mg$2kim$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a83kjb$1vtr$2 digitaldaemon.com...
 Try this for, say, a delay of 1 hundreth of a second:
     if ((clock() - t) >= CLOCKS_PER_SEC / 100)
 The division is done at compile time.


It's an old trick <g>.
 But... not so fast! I don't like the name of the constant! =)

Nobody's ever happy!
 Probably something like TicksPerSecond would be better?

Probably. I just threw out the former because that's what C uses.
Mar 30 2002
prev sibling parent Russell Borogove <kaleja estarcion.com> writes:
DrWhat? wrote:
So, how about it? An extended for a datetime?

1 converting time -> seconds is none trivial

seconds_into_the_day = fmod( days, 1.0 ) * 86400; // == 60*60*24
Mar 28 2002