July 15, 2004
"pragma" <EricAnderton at yahoo dot compragma_member@pathlink.com> escribió
en el
mensaje news:cd6i9v$2as9$1@digitaldaemon.com
| In article <cd68nd$271p$1@digitaldaemon.com>, Stewart Gordon says...
|| We'd have to decide on a system for format strings.
||
|| I had been thinking about a system like this:
||
|| dd MMM yyyy 15 JUL 2004
|| Wwww 'the' ddt 'of' Mmmm Thursday the 15th of July
|| h:ii:ss pp 4:25:10 pm
|| HH:ii:ss 16:25:10
|| yyyy-mm-dd HH:ii:ss.lll 2004-07-15 16:25:10.254
|
| Sounds like a soild start.  I may throw some suggestions for this back
into the
| NG later, if you like? :)
|

I already wrote a toString function, taking a d_time and a char [] (to specify the format). It's available in the Wiki in the Phobos additions section, and I also mentioned it once in dsource in the Deimos forum.

-----------------------
Carlos Santander Bernal


July 15, 2004
"Stewart Gordon" <smjg_1998@yahoo.com> escribió en el mensaje
news:cd68nd$271p$1@digitaldaemon.com
| The only trouble with streams is that writef hasn't been put into them.
|   I've written the code to do this and posted it here the other day ...
| hopefully they'll actually be put in.

... which I can't get to work: they cause AV.

-----------------------
Carlos Santander Bernal


July 16, 2004
Stewart Gordon wrote:

> Jonathan Leffler wrote:
> <snip>
> 
>> Sub-second precision?  Please?
>>
>> And the 'UTC time'; what range do you have in mind?  Within a single day, or since 1970-01-01 00:00:00+00:00, or some other epoch?
> 
> My thought is that TimeValue would represent a time within a single day, in milliseconds since midnight UTC.

Well, milliseconds is better than integral seconds; going all the way to nanoseconds might be overkill - though POSIX/SUS does that.  Given that you're probably planning on using 32-bit unsigned quantities and that there are 86,400 seconds in a day, you could nominally work in 0.1 millisecond units (but not in 0.01 millisecond units), and it isn't worth doing that.  So, you have some large integral number of days (16 bits are not adequate as a signed quantity only allows about +/-90 years from your chosen epoch, so you need 32 bits for the days), plus 32 bits for the time of day in milliseconds since midnight, and presumably a 16 bit signed offset for the time zone - in minutes. That won't represent all historical time zones (you'd need milliseconds offsets for some of those), but it will manage all modern current civil time zones (which are actually multiples of 15 minutes offset from UTC -- Newfoundland and India are on half hour time zones, and Nepal is on a quarter hour time zone, primarily to emphasize that is isn't India).

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

> "Stewart Gordon" <smjg_1998@yahoo.com> escribió en el mensaje
> news:cd68nd$271p$1@digitaldaemon.com
>> The only trouble with streams is that writef hasn't been put into them.  I've written the code to do this and posted it here the other day ... hopefully they'll actually be put in.
> 
> ... which I can't get to work: they cause AV.

At least I thought I'd tested it.  Would you care to supply a code sample?

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 16, 2004
Jonathan Leffler wrote:

<snip>
> Well, milliseconds is better than integral seconds; going all the way to nanoseconds might be overkill - though POSIX/SUS does that.  Given that you're probably planning on using 32-bit unsigned quantities and that there are 86,400 seconds in a day, you could nominally work in 0.1 millisecond units (but not in 0.01 millisecond units), and it isn't worth doing that.  So, you have some large integral number of days (16 bits are not adequate as a signed quantity only allows about +/-90 years from your chosen epoch, so you need 32 bits for the days), plus 32 bits for the time of day in milliseconds since midnight,

Yes, that's exactly what I said.

> and presumably a 16 bit signed offset for the time zone - in minutes.

If you've been following the thread, you'll have noticed that there's been a debate on whether each time should have a zone attached.  The current plan is to just have it as a global setting.  Keeping it with every time object would bloat memory usage a bit for most purposes.  But yes, offsets in minutes are one of the basic design ideas.

> That won't represent all historical time zones (you'd need milliseconds offsets for some of those),

Did they actually have discrete time zones in those days?  Or a continuum?

> but it will manage all modern current civil time zones (which are actually multiples of 15 minutes offset from UTC -- Newfoundland and India are on half hour time zones, and Nepal is on a quarter hour time zone, primarily to emphasize that is isn't India).

So I'd gathered.  But I hadn't gathered where the quarter-hour zones are.  If the settings of my mobile phone are anything to go by, then there are 25 whole-hour offsets (-12:00 to +12:00), 10 half-hour offsets (-09:30, -08:30, -03:30, +03:30, +04:30, +05:30, +06:30, +09:30, +10:30, +11:30) and two quarter-hour offsets (+05:45, +12:45).  That's before you count DST....

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 17, 2004
"Stewart Gordon" <smjg_1998@yahoo.com> escribió en el mensaje
news:cd89l8$383$2@digitaldaemon.com
| Carlos Santander B. wrote:
|
|| "Stewart Gordon" <smjg_1998@yahoo.com> escribió en el mensaje
|| news:cd68nd$271p$1@digitaldaemon.com
||| The only trouble with streams is that writef hasn't been put into them.
||| I've written the code to do this and posted it here the other day ...
||| hopefully they'll actually be put in.
||
|| ... which I can't get to work: they cause AV.
|
| At least I thought I'd tested it.  Would you care to supply a code sample?
|
| 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.

Here's the code I tested (dmd 0.95, win xp pro and win 95):

//////////////////////
import std.stream;

void main ()
{
    stdout.writefln("hello world");  // <- AV
    stdout.writef("hello world\n");  // <- unable to move file pointer

    File f = new File("output",FileMode.Out);
    f.writefln("hello world");  // <- AV
    f.writef("hello world\n");  // <- AV
    f.close();
}

//////////////////////

-----------------------
Carlos Santander Bernal


July 17, 2004
Stewart Gordon wrote:

> Jonathan Leffler wrote:
> <snip>
>> Well, milliseconds is better [...]
> Yes, that's exactly what I said.

Yes, and I repeated it with justifications as I went - sorry.  There was an echo in the room, or something.

>> and presumably a 16 bit signed offset for the time zone - in minutes.
> 
> If you've been following the thread, you'll have noticed that there's been a debate on whether each time should have a zone attached.  The current plan is to just have it as a global setting.  Keeping it with every time object would bloat memory usage a bit for most purposes.  But yes, offsets in minutes are one of the basic design ideas.

Different people will have different views on that.  The SQL standard, FWIW, provides both TIME and TIME WITH TIMEZONE (and TIMESTAMP and TIMESTAMP WITH TIMEZONE - time stamps include date as well as time).

When you know from the context what the time zone is, and that it applies to every time, the global is fine.  However, if you need to deal with orders from around the world (a web site), you might be interested to know what the local time was at the customer's site as well as at the web site.

>> That won't represent all historical time zones (you'd need milliseconds offsets for some of those), 
> 
> Did they actually have discrete time zones in those days?  Or a continuum?

I forget the exact values, but it wasn't a continuum - for example, the Netherlands used an offset from GMT (this pre-dates UTC by half a century or so) that was N minutes and M.XYZ seconds different.  It represented rather accurately the difference between the Greenwich meridian and a suitable point in the Netherlands - perhaps an observatory near Amsterdam.

>> but it will manage all modern current civil time zones (which are actually multiples of 15 minutes offset from UTC -- Newfoundland and India are on half hour time zones, and Nepal is on a quarter hour time zone, primarily to emphasize that is isn't India).
> 
> 
> So I'd gathered.  But I hadn't gathered where the quarter-hour zones are.  If the settings of my mobile phone are anything to go by, then there are 25 whole-hour offsets (-12:00 to +12:00), 10 half-hour offsets (-09:30, -08:30, -03:30, +03:30, +04:30, +05:30, +06:30, +09:30, +10:30, +11:30) and two quarter-hour offsets (+05:45, +12:45).  That's before you count DST....

+05:45 would be Nepal; +12:45 would be somewhere in the Pacific.  One of the more interesting problems is that ISO 8601 defines time zone offsets such that points east have positive time zones, but Unix and hence POSIX defines them such that points west have positive time zones.  Isn't standardization wonderful - two choices, and both are standard!


-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
July 17, 2004
Found this while wandering around: http://www.cise.ufl.edu/~sbeck/DateManip.html

It has some ideas worth glancing at, including a "business mode" (think UPS
delivery!).

- Kris


"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ccbcv8$1lpt$1@digitaldaemon.com...
> 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 18, 2004
Kris wrote:

> Found this while wandering around:
> http://www.cise.ufl.edu/~sbeck/DateManip.html
> 
> It has some ideas worth glancing at, including a "business mode" (think UPS
> delivery!).


Also http://datetime.perl.org/

Lots and lots of ideas.


-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
July 19, 2004
Carlos Santander B. wrote:
> "Stewart Gordon" <smjg_1998@yahoo.com> escribió en el mensaje news:cd89l8$383$2@digitaldaemon.com
>> Carlos Santander B.  wrote:
>> 
>>> "Stewart Gordon" <smjg_1998@yahoo.com> escribió en el mensaje news:cd68nd$271p$1@digitaldaemon.com
>>>> The only trouble with streams is that writef hasn't been put into them.  I've written the code to do this and posted it here the other day ...  hopefully they'll actually be put in.
>>> 
>>> ...  which I can't get to work: they cause AV.
>> 
>> At least I thought I'd tested it.  Would you care to supply a code sample?  Here's the code I tested (dmd 0.95, win xp pro and win 95):
<snip>

Thanks - I don't know why it doesn't work, but I'll take a look.  I'm guessing that there are problems (which I've a feeling have been seen before) with functions within functions within classes, or something.

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.