-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: think about imprecise dates & times #41
Comments
Hmm I can see the benefits, but I've actually been stripping out types over the past year to keep the complexity as low as I can. I think this might be one of those cases that would be best served with a custom type. I think the same would go for week-of-year situations. I've worked in banks before, and it is an important type for them, but not widespread enough to warrant forcing everyone to support it... I might be missing the importance and this might be dealbreaker level wrong. If so, I welcome people to chime in! |
I think custom types should suffice. In both cases where I’ve had to deal with imprecise date/times interoperability with external systems wasn’t a concern. |
ISO week numbers are very commonly used in Sweden (and I think the other Nordic countries) in everyday life. For example, people will talk about taking a vacation in week 31. |
Yup, also Julian dates are very common in accounting software. But additions such as these (while quite useful) would increase the footprint and complexity of the format. In order to avoid too much creep, Concise Encoding adopts the philosophy: Not a human data format that a machine can read, but rather a machine data format that a human can read. So taking the ISO week numbers as an example, a computer program would implement it either as a simple integer with a range constraint, or it would translate under the hood to a date range and use that, converting back in the UI as needed. What Concise Encoding is interested in is what actual data the machines are communicating to each other, not the human presentation of that data (for which we have touchie-feelie user interfaces). |
Stumbled upon your project on today's Ask HN.
It may be too much trouble for too little gain, but something I've had to deal with in recent years that has effectively no support from programming languages/libraries that I've used are imprecise dates and times.
2020-08 (August 2020) is a legitimate concept to wish to encode, and representing it as 2020-08-01 or any other specific day of the month would be adding precision where none exists.
Another date-related note: week numbers from ISO 8601 are apparently quite important for some contexts.
Good luck, this is an interesting project.
The text was updated successfully, but these errors were encountered: