Okay. At the moment, the time point types in std.datetime have functions for converting to and from strings of standard formats but not custom formats, so functions for that need to be added. I've come up with a proposal for how they're going to work and would like some feedback on it.

Originally, I was going to make them work like strftime and strptime, since it was my understanding that those functions were fairly standard among various programming languags. And it _does_ look like a variety of programming languages have something similar (Java, Ruby, Python, etc.), but the exact set of flags that they use is not standard, so there _isn't_ really a standard to follow, just similar functions across a variety of programming languages. And honestly, strftime and strptime aren't very good. They're fairly limited IMHO, and the choice of flags is fairly arbitrary, so it seems like a good idea to design our own, assuming that we can make something better.

Stewart Gordon has a library that takes a different approach ( http://pr.stewartsplace.org.uk/d/sutil/datetime_format.html ). It does away with % flags and uses maximul munch with each of the flags being name such that they don't overlap in a way that would make certain combinations of flags impossible. It then requires that characters which are not part of the flags be surrounded by single quotes. It's an interesting approach, but it isn't as flexible as it could be because of its use of maximul munch instead of % flags.

So, I've come up with something new which tries to take the best of both. On the whole, I think that it's fairly straightforward, and the flags are generally recognizable and memorable (though there are a lot). It's also definitely extremely flexible (e.g. you can pass it functions to generate portions of the string if the existing flags don't get you quite what you need). But I'd like some feedback on it before I spend a lot of time on the implementation.

This page has the docs for std.datetime with everything else but the proposed custom formatting functions for SysTime stripped out of it:

http://jmdavis.github.com/d-programming-language.org/std_datetime.html

So, what do you think?

- Jonathan M Davis

My first thought is that std.datetime is already very large. Few will need a custom date formatter, so it should be in a separate module to:

1. reduce cognitive load on the programmer

2. reduce the overhead pulled in for every program that may want to use an std.datetime function, but not need custom formatting

On Wednesday, December 21, 2011 19:57:28 Walter Bright wrote:
> My first thought is that std.datetime is already very large. Few will need a custom date formatter, so it should be in a separate module to:
> 
> 1. reduce cognitive load on the programmer
> 
> 2. reduce the overhead pulled in for every program that may want to use an std.datetime function, but not need custom formatting

It makes by far the most sense to put it on the types themselves IMHO (especilaly since all of the other string functions are that way), and the functions are templated, so the overhead is reduced if you don't use them.

If we want to address the size of std.datetime, I believe that there are far better ways to do it. Breaking out the benchmarking stuff (which we're likely to do) would be one. Another would be to take the interval and range stuff and put it in a separate module. It uses the time point stuff, but doesn't need to be in the same module to do what it does.

Yes, putting the custom formatting functions in increases the size of the module, but I think that if we want to do something about the size of std.datetime, it would make more sense to move some of its existing pieces out than to not put the custom time formatting on the types themselves.

- Jonathan M Davis

On Thursday, 22 December 2011 at 03:42:32 UTC, Jonathan M Davis wrote:
> http://jmdavis.github.com/d-programming-language.org/std_datetime.html

What is the purpose of %nyplus ?

There should be presets for common standard date formats, like here:
http://php.net/manual/en/class.datetime.php#datetime.constants.types

On Thursday, December 22, 2011 05:19:07 Vladimir Panteleev wrote:
> On Thursday, 22 December 2011 at 03:42:32 UTC, Jonathan M Davis
> 
> wrote:
> > http://jmdavis.github.com/d-programming-language.org/std_datetime.html
> 
> What is the purpose of %nyplus ?

It's what the ISO formats use. They put a + in front of the number if it's positive and exceeds 4 digits. %yplus would put the + there as long as the year is positive, whereas %4yplus puts it there if the year is > 9999.

> There should be presets for common standard date formats, like here: http://php.net/manual/en/class.datetime.php#datetime.constants.types

Those could be added, though I'd probably add them as additional flags. It already has %ctime and %mpeg7, but those are some good ones to add as well.

- Jonathan M Davis

On 12/21/2011 8:12 PM, Jonathan M Davis wrote:
> Yes, putting the custom formatting functions in increases the size of the
> module, but I think that if we want to do something about the size of
> std.datetime, it would make more sense to move some of its existing pieces out
> than to not put the custom time formatting on the types themselves.


I would seriously like to change to a "pay only for what you use" model for Phobos.

Note that a module can be split into sub-modules without changing the interface for the user.

On Wednesday, December 21, 2011 22:22:40 Walter Bright wrote:
> On 12/21/2011 8:12 PM, Jonathan M Davis wrote:
> > Yes, putting the custom formatting functions in increases the size of
> > the
> > module, but I think that if we want to do something about the size of
> > std.datetime, it would make more sense to move some of its existing
> > pieces out than to not put the custom time formatting on the types
> > themselves.
> I would seriously like to change to a "pay only for what you use" model for Phobos.

In general, I agree that that's a good policy. How expensive would you consider templated functions which aren't used to be with regards to that? They don't cost nothing, since they still have to be lexed and parsed, but they don't get fully compiled.

> Note that a module can be split into sub-modules without changing the interface for the user.

You mean create other modules that get publicly imported by one module? I do think that sections of std.datetime would benefit from that.

- Jonathan M Davis

On 12/21/2011 10:36 PM, Jonathan M Davis wrote:
> In general, I agree that that's a good policy. How expensive would you
> consider templated functions which aren't used to be with regards to that?
> They don't cost nothing, since they still have to be lexed and parsed, but
> they don't get fully compiled.

The test is to import the module without referencing any functions in it. Check if the resulting executable increases in size.

>> Note that a module can be split into sub-modules without changing the
>> interface for the user.
>
> You mean create other modules that get publicly imported by one module? I do
> think that sections of std.datetime would benefit from that.

Yes.

On Wednesday, December 21, 2011 22:46:37 Walter Bright wrote:
> On 12/21/2011 10:36 PM, Jonathan M Davis wrote:
> > In general, I agree that that's a good policy. How expensive would you consider templated functions which aren't used to be with regards to that? They don't cost nothing, since they still have to be lexed and parsed, but they don't get fully compiled.
> 
> The test is to import the module without referencing any functions in it. Check if the resulting executable increases in size.

Isn't that a compiler and/or linker issue? I mean, if _nothing_ is referenced in the module, then shouldn't it never pull anything in and therefore never increase the size of the executable?

- Jonathan M Davis

On 2011-12-22 04:57, Walter Bright wrote:
> My first thought is that std.datetime is already very large. Few will
> need a custom date formatter, so it should be in a separate module to:
>
> 1. reduce cognitive load on the programmer
>
> 2. reduce the overhead pulled in for every program that may want to use
> an std.datetime function, but not need custom formatting

As I've said several times, std.datetime is way too large and should be a package.

-- 
/Jacob Carlborg