4 ms·

When designing a new API, it makes sense to consider this kind of thing: How are people going to use it, and how are people going to screw it up? Kids these day

by geocar 8y ago

When designing a new API, it makes sense to consider this kind of thing: How are people going to use it, and how are people going to screw it up? Kids these days copy and paste everything so bugs tend to multiply if you (god forbid) make a popular API. Date formatter APIs are opaque and anyone trying to use one in the morning or before the 12th day of a month has to check the documentation, so what do we actually gain with this abstraction? There's a small number of formats you might need that it makes sense to try to enumerate them: * ISO8601 (and get it right, it's a comma not a dot) * that weird ISO8601 variant that uses a dot * kdb's .z.p * DJB's TAI * ISO/IEC 9899 asctime/ctime * IEEE 1003.1 "ls" format * Yankee-doodle format/other localised formats * RFC1123/RFC7231 * RFC2109 * RFC822/RFC2822 * Fancy "X units since/until" relative time Do you really need so many others that you should have "yyyy-MM-dd" anywhere in your code? Each of these are trivial to construct from a struct tm/Date object, that you'll end up with fewer bugs if you stop making up mini-languages for dates and just do it directly. Oh and your code will be faster.

_trampeltier 8y ago
And then is the funny idea with an unknown date of birth, when you end up with 00-00-yyyy in your passport.
- geocar 8y ago
  Yes! That's a very good point! How is a data-formatting mini-language supposed to sensibly deal with this? RFC3339 specifically prohibits the idea of unknown dates/months...
  - acdha 8y ago
    There are proposed extensions — for example, the Library of Congress[1] has proposed "X" for unknown field values and ".." for when only one part of a range is known: https://www.loc.gov/standards/datetime/edtf.html https://www.loc.gov/standards/datetime/edtf.html 1. Disclaimer: my employer but I don't work in that group or on that project
    - geocar 8y ago
      Thanks for that. I think this begs for a better "date" object though, rather than an advocate for the programmable formatter, no?
    - Zardoz84 8y ago
      oh man... I found these kind of dates dealing with MARC21 records. It's a problem as enforces us to duplicate data and use some complex replaces on SQL when we need to do queries by date.
ivan_gammel 8y ago
Support of legacy data formats is one of the reasons. Of course, it’s very unlikely that someone would ever use dd-MM-YYYY intentionally.
- geocar 8y ago
  Why exactly do you think a legacy format will benefit from a special mini-language? It's not going to be faster, and as we can see: It's more likely to have bugs.
  - ivan_gammel 8y ago
    Because it's a compact and user-friendly form of specifying such formats. Some strange behavior in edge cases doesn't invalidate the benefits of not writing a new parser any time you need to handle some old representation of date.
fanf2 8y ago
Both comma and dot are allowed. My copy of ISO 8601-2004 says in section 4.2.2.4 “Representations with decimal fraction“: << If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign. >> Also, RFC 3339 is useful to have as a specific standard profile of ISO 8601, because 8601 comprises several formats with lots of options.
- geocar 8y ago
  > Both comma and dot are allowed. They are distinct formats: You're not going to alternate them in your output. You're going to output one or the other. > Also, RFC 3339 is useful to have as a specific standard profile of ISO 8601, because 8601 comprises several formats with lots of options. RFC3339 describes ISO8601 well enough. Is there something you think I missed?
  - fanf2 8y ago
    I didn't notice any glaring omissions, tho if you are including DJB's binary format you should also include the NTP and PTP scales. RFC 3339 doesn't include the ISO 8601 week calendar formats, nor does it include the 8601 syntax for time periods. 3339 is a lot simpler than 8601.
eadmund 8y ago
> and get it right, it's a comma not a dot I would have upvoted your comment but for this. In the Anglosphere, we always and without exception use a dot for decimal fractions. Yes, many other cultures use a comma, but when writing English (as you yourself do) one always and without exception uses a dot. (yes, I'm aware that ISO 8601:2004 states that the comma is preferred: it’s simply wrong)

by geocar 8y ago

_trampeltier 8y ago

And then is the funny idea with an unknown date of birth, when you end up with 00-00-yyyy in your passport.

geocar 8y ago
Yes! That's a very good point! How is a data-formatting mini-language supposed to sensibly deal with this? RFC3339 specifically prohibits the idea of unknown dates/months...
- acdha 8y ago
  There are proposed extensions — for example, the Library of Congress[1] has proposed "X" for unknown field values and ".." for when only one part of a range is known: https://www.loc.gov/standards/datetime/edtf.html https://www.loc.gov/standards/datetime/edtf.html 1. Disclaimer: my employer but I don't work in that group or on that project
  - geocar 8y ago
    Thanks for that. I think this begs for a better "date" object though, rather than an advocate for the programmable formatter, no?
  - Zardoz84 8y ago
    oh man... I found these kind of dates dealing with MARC21 records. It's a problem as enforces us to duplicate data and use some complex replaces on SQL when we need to do queries by date.

ivan_gammel 8y ago

Support of legacy data formats is one of the reasons. Of course, it’s very unlikely that someone would ever use dd-MM-YYYY intentionally.

geocar 8y ago
Why exactly do you think a legacy format will benefit from a special mini-language? It's not going to be faster, and as we can see: It's more likely to have bugs.
- ivan_gammel 8y ago
  Because it's a compact and user-friendly form of specifying such formats. Some strange behavior in edge cases doesn't invalidate the benefits of not writing a new parser any time you need to handle some old representation of date.

fanf2 8y ago

Both comma and dot are allowed. My copy of ISO 8601-2004 says in section 4.2.2.4 “Representations with decimal fraction“: << If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign. >> Also, RFC 3339 is useful to have as a specific standard profile of ISO 8601, because 8601 comprises several formats with lots of options.

geocar 8y ago
> Both comma and dot are allowed. They are distinct formats: You're not going to alternate them in your output. You're going to output one or the other. > Also, RFC 3339 is useful to have as a specific standard profile of ISO 8601, because 8601 comprises several formats with lots of options. RFC3339 describes ISO8601 well enough. Is there something you think I missed?
- fanf2 8y ago
  I didn't notice any glaring omissions, tho if you are including DJB's binary format you should also include the NTP and PTP scales. RFC 3339 doesn't include the ISO 8601 week calendar formats, nor does it include the 8601 syntax for time periods. 3339 is a lot simpler than 8601.

eadmund 8y ago

> and get it right, it's a comma not a dot I would have upvoted your comment but for this. In the Anglosphere, we always and without exception use a dot for decimal fractions. Yes, many other cultures use a comma, but when writing English (as you yourself do) one always and without exception uses a dot. (yes, I'm aware that ISO 8601:2004 states that the comma is preferred: it’s simply wrong)