Simplified unix epoch time

Yes, this is on the way :)

any ideas for this, Steve?

After some thought, there doesn't seem to be a real compelling reason to have a separate tango-only function that does the equivalent of time(null). I think keeping the API clean and having only one time base overrides having the convenience and support of Unix time also. We probably would then have to add Windows time.

I think the current method of either using time(null) or calculating by using the epoch constants is sufficient for most people's needs.

That being said, I did add to the documentation methods on how to calculate unix time from tango time, which should be beneficial to users who must work with unix time from other libraries.

(In [3167]) Added more documentation to help explain how Tango time relates to Unix time (references #763)

I'm late into the game, but I heartily disagree with the resolution of this ticket. Whether you like it or not, the unix epoch is the base for most default time values in use. Whether this is smart or not, I won't discuss - but I find it disconcerting that I have to retort to uglyness if I would like to interact with my current Java applications (something I really want to do).

An example (although very oldish in the Java world, I frequently have to work with it - meaning it is the common denominator to use when storing in databases, passing over various protocols, etc):

long timestamp = (new Date()).getTime();

BTW, I'm not a huge fan of this. I still think the domain of 'converting to my favorite time system' should be up to the project that needs that time system.

Note that Java doesn't provide any functions to auto-convert to other time systems...

Proposed module to handle time conversions between different time systems

Kris, your thoughts on this?

Hate to say it, but I suspect these should live somewhere in Time.d instead. If that were the case, I'd drop the Win32 stuff.

If it remains as an external module, I'd version() the Win32 ugliness to make it at least compile on linux, and I'd call the module something other than Convert. Of course, that would raise a question as to why the Win32 time should be version'd while the unix time is not :)

The win32 stuff is not OS dependent. I'm just importing a struct definition. It should compile on Linux.

This would be required if you wanted a cross-platform tool that supported some protocol or format that used FILETIME. Unlikely, but it seems appropriate that we treat all OSes equally if we are going to provide this functionality at all.

I thought Time was supposed to be free of unneeded implementation? Otherwise, why don't we put toString in there too? Why should I have to import a function that converts to Java time when I never use it?

Why should it not be named Convert? Do you have an alternate suggestion?

I'm thinking I should close this ticket, and make a new one that is more generally for time conversion, but I dunno. There was recently someone asking for something aka :

parse("2008-09-08", "YYYY-MM-DD");

Also, toJavaTime is a silly name - it is a unix timestamp in milliseconds, hardly anything Java specific.

Replying to larsivi:

I'm thinking I should close this ticket, and make a new one that is more generally for time conversion, but I dunno. There was recently someone asking for something aka : parse("2008-09-08", "YYYY-MM-DD"); Also, toJavaTime is a silly name - it is a unix timestamp in milliseconds, hardly anything Java specific.

That kinda thing currently resides in tango.text.convert.TimeStamp, though perhaps not with that explicit function

Replying to schveiguy:

The win32 stuff is not OS dependent. I'm just importing a struct definition. It should compile on Linux.

We generally try to avoid importing O/S specific stuff on the wrong platform. For example: attempting to import stdc.posix on Win32 will generally fail, for obscure reasons.

This would be required if you wanted a cross-platform tool that supported some protocol or format that used FILETIME. Unlikely, but it seems appropriate that we treat all OSes equally if we are going to provide this functionality at all.

Which is why I suggested dropping the FILETIME support, if it were moved into the Time module :)

I thought Time was supposed to be free of unneeded implementation? Otherwise, why don't we put toString in there too? Why should I have to import a function that converts to Java time when I never use it?

It wouldn't import anything. The function could be defined within the Time struct, if appropriate. No additional imports, so no problem. However, that's why such a scheme would not support a FILETIME implementation. The Java millisecond and Unix second variations of Epoch1970 would be OK though. While not pure in any sense of the phrase, they're perhaps sufficiently common to warrant inclusion?

Why should it not be named Convert? Do you have an alternate suggestion?

Because we do at least make some effort to avoid using the same name in multiple packages. I'm sure we could come up with an alternative if necessary. Still, people bitch about tango.time being too difficult to use, and I suspect adding yet another module (for something like this) will not help to alleviate such concerns?

OK, what about having a member function that returns a TimeSpan, which can then be used to get the seconds or milliseconds (or whatever) as appropriate?

i.e.:

// inside Time struct
TimeSpan unix() { return *this - epoch1970; }
...

// usage:
auto unixtime = Clock.now.unix.seconds;
auto javatime = Clock.now.unix.millis;

I have a lot less worry about this, because the time type is still retained, it just makes the calculation look prettier.

The drawback is people might whine that they have to specify seconds? But if you guys are ok with this solution, then I'm fine with adding it this way.

Also, is unix a good name for the accessor, or is there something better you guys have in mind?

Seems good to me.

Can you explicitly optimize/code that unix() function implementation please?

(In [4037]) Added accessor for unix time to Time struct.

Closes #763