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

"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
bit
> (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
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.

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

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.

"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
> 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.

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.

"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.

"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

"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
boolean
> 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.

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

"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
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

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?

"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
believe,
> 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