digitalmars.D.announce - Proposal for date/time format strings
- Stewart Gordon (16/16) Sep 29 2005 I've drawn up a proposal for a format for date/time format strings
- Don Clugston (15/27) Sep 29 2005 Clearly better than anything else I've seen.
- Stewart Gordon (22/30) Sep 29 2005 What are you meaning by "time designations" exactly? First we were
- Uwe Salomon (13/13) Sep 29 2005 Look into the Unicode locale data repositary at
- Kris (9/25) Sep 29 2005 Might I suggest you provide a matching date/time parser? I think many fo...
- pragma (4/35) Sep 29 2005 I think Kris meant this url:
- pragma (28/35) Sep 29 2005 Looks awesome. Quite possibly the most sane rendition of such a thing I...
- Stewart Gordon (30/45) Sep 30 2005 That'll follow for as long as Gregorian is the only calendar supported.
- =?iso-8859-1?q?Knud_S=F8rensen?= (3/15) Oct 10 2005 You forgot the most important format: Seconds since the unix epoch.
-
Stewart Gordon
(13/16)
Oct 11 2005
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
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
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.<snip> 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
"Uwe Salomon" <post uwesalomon.de> 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
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
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
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.phpComments?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
pragma wrote:In article <dhgsfr$2cle$1 digitaldaemon.com>, Stewart Gordon says...<snip>- 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
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
Knud Sørensen wrote:You forgot the most important format: Seconds since the unix epoch. http://en.wikipedia.org/wiki/Unix_epoch<snip> 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