www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Proposal for date/time format strings

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
I've drawn up a proposal for a format for date/time format strings 
that's a little more natural-looking, logical and extensible than some 
I've seen.

http://pr.stewartsplace.org.uk/d/sutil/datetime_format.html

Hopefully this will find its way into the next version of Stewart's 
Utility Library.

Comments?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Sep 29 2005
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 I've drawn up a proposal for a format for date/time format strings 
 that's a little more natural-looking, logical and extensible than some 
 I've seen.
 
 http://pr.stewartsplace.org.uk/d/sutil/datetime_format.html
 
 Hopefully this will find its way into the next version of Stewart's 
 Utility Library.
 
 Comments?
 
 Stewart.

Clearly better than anything else I've seen. With regard to the open issues: * Mid-sentence case can obviously be mMm, wWw, but I really think the app would have to deal with it specially. * BC/AD and BCE/CE are reasonably universal standards. After all, AD is Latin, not English. I don't think any extant calendar has more than two time designations. Hebrew, Islamic, Buddhist and Chinese each only have two. The zero date, and the year length do depend on the calender (eg Islamic calender) and if you try to support them, you open a truly horrible can of worms. On some whacky calenders, the number of months isn't even constant. Looks great. Hope to see it replacing std.date eventually. -Don.
Sep 29 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
<snip>
 * BC/AD and BCE/CE are reasonably universal standards. After all, AD is 
 Latin, not English.
 I don't think any extant calendar has more than two time designations.
 Hebrew, Islamic, Buddhist and Chinese each only have two.

What are you meaning by "time designations" exactly? First we were talking about the two notations BC/AD and BCE/CE, which surely aren't part of the _calendar_. So I'm not sure how/if this is supposed to follow....
 The zero date, and the year length do depend on the calender (eg Islamic 
 calender) and if you try to support them, you open a truly horrible can 
 of worms. On some whacky calenders, the number of months isn't even 
 constant.

Yes, the Hebrew calendar has 13 months in some years and 12 months in others. The question is: How are the months numbered in this respect? Is Adar in a non-leap year month 12 or month 13? Of course, we'll need to write the functions to manipulate dates in other calendars before we support formatting in them. That is itself another piece of work altogether. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 29 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
Look into the Unicode locale data repositary at  
http://www.unicode.org/cldr/ for information about the different  
calendars. They are stored in an XML format there. The calendar issues are  
quite complex, and really supporting localized calendar strings is a nice  
piece of work. I have already written a scanner that reads the number  
formatting information and stores them in an internal format, and a module  
to format numbers according to this format (for Indigo). That was already  
very difficult. But calendar formatting includes localized number  
formatting, localized (i.e. translated) strings for day/month/year/epoch  
names, and different calculation schemes for the calendar types.

By the way, the Japanese calendar has several hundred time epochs, i think.

Ciao
uwe
Sep 29 2005
prev sibling next sibling parent reply "Kris" <fu bar.com> writes:
Might I suggest you provide a matching date/time parser? I think many folk
find that aspect much more difficult to wrangle than the formatting task,
per se.

For example: mango.time.Rfc1123 provides both formatting and parsing of
common Internet
formats(http://svn.dsource.org/projects/mango/trunk/time/Rfc1123.d)

- Kris


"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:dhgsfr$2cle$1 digitaldaemon.com...
 I've drawn up a proposal for a format for date/time format strings
 that's a little more natural-looking, logical and extensible than some
 I've seen.

 http://pr.stewartsplace.org.uk/d/sutil/datetime_format.html

 Hopefully this will find its way into the next version of Stewart's
 Utility Library.

 Comments?

 Stewart.

 -- 
 -----BEGIN GEEK CODE BLOCK-----
 Version: 3.1
 GCS/M d- s:- C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS-
 PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
 ------END GEEK CODE BLOCK------

 My e-mail is valid but not my primary mailbox.  Please keep replies on
 the 'group where everyone may benefit.

Sep 29 2005
parent pragma <pragma_member pathlink.com> writes:
I think Kris meant this url:

http://svn.dsource.org/projects/mango/trunk/mango/time/Rfc1123.d

- Eric

In article <dhhgi8$2v2i$1 digitaldaemon.com>, Kris says...
Might I suggest you provide a matching date/time parser? I think many folk
find that aspect much more difficult to wrangle than the formatting task,
per se.

For example: mango.time.Rfc1123 provides both formatting and parsing of
common Internet
formats(http://svn.dsource.org/projects/mango/trunk/time/Rfc1123.d)

- Kris


"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:dhgsfr$2cle$1 digitaldaemon.com...
 I've drawn up a proposal for a format for date/time format strings
 that's a little more natural-looking, logical and extensible than some
 I've seen.

 http://pr.stewartsplace.org.uk/d/sutil/datetime_format.html

 Hopefully this will find its way into the next version of Stewart's
 Utility Library.

 Comments?

 Stewart.

 -- 
 -----BEGIN GEEK CODE BLOCK-----
 Version: 3.1
 GCS/M d- s:- C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS-
 PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
 ------END GEEK CODE BLOCK------

 My e-mail is valid but not my primary mailbox.  Please keep replies on
 the 'group where everyone may benefit.


Sep 29 2005
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <dhgsfr$2cle$1 digitaldaemon.com>, Stewart Gordon says...
I've drawn up a proposal for a format for date/time format strings 
that's a little more natural-looking, logical and extensible than some 
I've seen.

http://pr.stewartsplace.org.uk/d/sutil/datetime_format.html

Hopefully this will find its way into the next version of Stewart's 
Utility Library.

Looks awesome. Quite possibly the most sane rendition of such a thing I've ever seen. Certainly a cut above this: http://us2.php.net/manual/en/function.date.php
Comments?

A bunch. :) - You may want to include a 'day of year' formatter in the same vein as the the other number formats. May I suggest the letter 'g' as this would be the Gregorian Calendar day of year? - Others have mentioned the Hebrew and Chinese calendars in this thread (I'll throw in the Julian calendar and the ISO-8601 specification for good measure). If you're serious about going the internationalization route by supporting these, then might I suggest wrapping this kernel of functionality into a "GregorianCalendar" class, which implements a "ICalendar" interface? That way other calendars, and their respective formatters, can fall into place under that common ICalendar interface. Then you can keep the various calendar formatters from stepping all over each other. - I'll echo what Kris mentioned: being able to parse things out is really key when working with dates. Are there any plans for a parser based on this scheme? :) - What will your algorithm do with formats that are neither clear text, nor decipherable according to your spec? Will it throw an exception on tokens like "MM" or "MMm"? - Have you given any thought about displaying time /spans/ via something like this? Its not too common a thing to use, but from time to time, it comes up; like displaying how many days a user has until their password expires. I guess that would require a different formatter under the hood, but it could easily use some of the same format specifiers. - EricAnderton at yahoo
Sep 29 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
pragma wrote:
 In article <dhgsfr$2cle$1 digitaldaemon.com>, Stewart Gordon says...

 - You may want to include a 'day of year' formatter in the same vein as the the
 other number formats.  May I suggest the letter 'g' as this would be the
 Gregorian Calendar day of year?

That'll follow for as long as Gregorian is the only calendar supported. But I suppose it doesn't really matter what the etymology of the chosen letter is, as long as people understand what it means. <snip>
 - I'll echo what Kris mentioned: being able to parse things out is really key
 when working with dates.  Are there any plans for a parser based on this
scheme?
 :)

Certainly a possibility. My library should eventually have parsing, and to base the parsing system on the formatting system is a good idea. We could even provide a means of supplying a list of formats that it will try to parse in order.
 - What will your algorithm do with formats that are neither clear text, nor
 decipherable according to your spec? 

All syntax errors would throw an exception.
 Will it throw an exception on tokens like "MM" or "MMm"?

Good question. But probably. "MMm" could be defined to generate e.g. "SEp", but would there be any practical use? Generalising this also conflicts with Don's idea (like one I had in mind myself) for supporting language-sensitive mid-sentence case.
 - Have you given any thought about displaying time /spans/ via something like
 this?  Its not too common a thing to use, but from time to time, it comes up;
 like displaying how many days a user has until their password expires.  I guess
 that would require a different formatter under the hood, but it could easily
use
 some of the same format specifiers.

That's exactly what the last open issue says. Of course, hours, minutes and seconds will transfer without any trouble to such a thing. But other measures are trickier - I'm guessing we should have weeks, days and the units below it and leave it at that. Maybe lowercase could mean 'past the next unit up' and uppercase can mean 'in total' or something. And how should we deal with positive vs. negative intervals? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 30 2005
prev sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
You forgot the most important format: Seconds since the unix epoch.

http://en.wikipedia.org/wiki/Unix_epoch



On Thu, 29 Sep 2005 15:07:55 +0100, Stewart Gordon wrote:

 I've drawn up a proposal for a format for date/time format strings 
 that's a little more natural-looking, logical and extensible than some 
 I've seen.
 
 http://pr.stewartsplace.org.uk/d/sutil/datetime_format.html
 
 Hopefully this will find its way into the next version of Stewart's 
 Utility Library.
 
 Comments?
 
 Stewart.

Oct 10 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Knud Sørensen wrote:
 You forgot the most important format: Seconds since the unix epoch.
 
 http://en.wikipedia.org/wiki/Unix_epoch

Why is this a more important aspect of human-readable date strings than such familiar units as year, month, day, hour, minute, second? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Oct 11 2005