I'm using D2.049. I have a program in which I want to be able to get the current time as one number, also be able to change the hour and stuff then convert it back to one number. I'm saving just the one number to file.

Thanks in advance. :-)

On Sat, 25 Sep 2010 18:47:39 -0500, Joel Christensen <joelcnz@gmail.com> wrote:

> I'm using D2.049. I have a program in which I want to be able to get the current time as one number, also be able to change the hour and stuff then convert it back to one number. I'm saving just the one number to file.
>
> Thanks in advance. :-)

std.datetime is your friend.

http://www.digitalmars.com/d/2.0/phobos/std_date.html

-- 
Yao G.

I've tried that module.

I was putting:
long dt = UTCtoLocalTime(getUTCtime - (msPerDay / 2));
Then when daylight savings came it was wrong, (computer was right mind).

long datetime = UTCtoLocalTime(getUTCtime);
It is 1 hour and half a day out. It was the right hour till daylight savings. I live in New Zealand.

Some one said that module was a mine field.

> std.datetime is your friend.
>
> http://www.digitalmars.com/d/2.0/phobos/std_date.html
>

On Saturday 25 September 2010 17:48:54 Joel Christensen wrote:
> I've tried that module.
> 
> I was putting:
> long dt = UTCtoLocalTime(getUTCtime - (msPerDay / 2));
> Then when daylight savings came it was wrong, (computer was right mind).
> 
> long datetime = UTCtoLocalTime(getUTCtime);
> It is 1 hour and half a day out. It was the right hour till daylight
> savings. I live in New Zealand.
> 
> Some one said that module was a mine field.

std.date is definitely broken. Some of it works, much doesn't. It is going to be
replaced by std.datetime which will have much better functionality for both
times and dates, but that hasn't been finished yet. Both Yao G. and I are working
on implementations which are going to be reviewed for possible inclusion in
phobos as std.datetime, and we're getting close to being done, but as I said,
it's not finished yet.

So, your best bet is to either mess around with std.date and figure out if you
can get the functionality you need to work one way or another (I think that I
ended up only ever using UTC in my code that used std.date since I couldn't get
it to properly print local time), or you can use the C API directly:
http://www.cppreference.com/wiki/c/date/start

I believe that core.sys.posix.time.d already has the appropriate prototypes for them in D (on posix systems at least).

- Jonathan M Davis

Thanks for the replies Jonathan M Davis and Yao G. :-)

Good to hear it's being worked on. I've other programs that are done with D1.0 that are all right.

I'm using Windows, would like it to work on Linux too though.

I think I'll use year month etc. separately instead of just having a big number (for converting to the time measurements).

How do you access the core library? I wanted to look at the core time module and couldn't, (C/C++ sites of course have that information any way).

On Saturday 25 September 2010 21:37:30 Joel Christensen wrote:
> Thanks for the replies Jonathan M Davis and Yao G. :-)
> 
> Good to hear it's being worked on. I've other programs that are done with D1.0 that are all right.
> 
> I'm using Windows, would like it to work on Linux too though.
> 
> I think I'll use year month etc. separately instead of just having a big number (for converting to the time measurements).
> 
> How do you access the core library? I wanted to look at the core time module and couldn't, (C/C++ sites of course have that information any way).

If you want to use it, just import it. e.g. import core.sys.posix.time; I don't see a corresponding set of definitons for Windows though, for some reason - I have no idea why.

If you want to look at the code, then look look in your dmd directory. It's in src/druntime/src/. core.sys.posix.time is src/druntime/src/core/sys/posix/time.d. From the little I've look at core though, the system stuff really isn't documented. It's pretty much just including proper declarations for C system stuff and giving a way for your to access it without directly putting the C declarations in your code yourself. It also deals with some of the differences on platforms, which can prove to be quite annoying - even among posix implementations.

Of course, the stuff you're looking for is standard C stuff, so you could just do it yourself directly - all it really requires is the function declarations. Check out http://www.digitalmars.com/d/2.0/interfaceToC.html for more details.

- Jonathan M Davis

Thanks Jonathan. My plan is to use the C version, and not use the big time_t number. I'm actually using std.c.stdio module too, for binary files, I probably should use std.stream or some thing.

On Saturday 25 September 2010 22:40:39 Joel Christensen wrote:
> Thanks Jonathan. My plan is to use the C version, and not use the big time_t number. I'm actually using std.c.stdio module too, for binary files, I probably should use std.stream or some thing.

Well, std.stdio will give you a way to read binary files, so you can use that, but you should probably avoid std.stream. As far as I know, it works just fine, but it's scheduled for deprecation as soon as a replacement has been decided on. std.stream is not range-based, and the phobos developers what streams in phobos to be range-based, so they plan to replace std.stream, but they're still trying to figure out what the best design for the the new std.stream should be, and so I have no idea when it'll actually be replaced.

- Jonathan M Davis

Thanks for your reply Jonathan. Yes, I heard about stream being replaced, but since my code with binary files isn't very much, I can just redo it if I have to. I think I'll continue using std.c.file for the time being.

I should learn about ranges.

I tried std.stdio already.

It's been been good getting replies here. :-)

On Sunday 26 September 2010 00:23:23 Joel Christensen wrote:
> Thanks for your reply Jonathan. Yes, I heard about stream being replaced, but since my code with binary files isn't very much, I can just redo it if I have to. I think I'll continue using std.c.file for the time being.
> 
> I should learn about ranges.

You'll be able to do a lot more with stuff like std.algorithm if you have a good understanding of ranges (I should also note that std.algorithm is a prime example of why auto is such a good thing - you do _not_ want to have to use all of the specific return types in std.algorithm directly).

This article by Andrei would be a good place to start: http://www.informit.com/articles/article.aspx?p=1407357

There's also this presentation that he did on ranges at BoostCon 2009: http://blip.tv/file/2432106

They require you to think differently about some things, but for a lot of stuff, it can be very powerful and much simpler to do. One really cool thing is that you can process a range pretty much like you'd process an slist in a functional language like lisp or Haskell (you can use front and popFront() very similarly to how head/car and tail/cdr are used in function languages).

I really love ranges, but they can take some getting used to. A lot of folks seme to react fairly negatively to them intially, but once you've messed with them a bit, you'll probably agree that in most cases, they're at least as good if not superior to iterators.

- Jonathan M Davis