Skip to content
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

Open
macintux opened this issue Jan 1, 2022 · 4 comments
Open

Suggestion: think about imprecise dates & times #41

macintux opened this issue Jan 1, 2022 · 4 comments

Comments

@macintux
Copy link

macintux commented Jan 1, 2022

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.

@kstenerud
Copy link
Owner

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!

@macintux
Copy link
Author

macintux commented Jan 1, 2022

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.

@kevinior
Copy link

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.

@kstenerud
Copy link
Owner

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants