41–50 of 94 posts
Earlier quoted context omitted.
Is there something similar for Python or JavaScript?
eslint is the de facto standard for Javascript, there may be rules or plugins to check for date formatting rules.
Earlier quoted context omitted.
> Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great? Yes, but it would not have helped with the bug in question. The parallel bug for a strongly typed interface would be "year()" returning this monstrosity, while "iso_year()" or some other poorly named variant returning the expected year. No API is immune to footguns and bad design d…
I forgot how bad JS's date API was until I tried getting the year out of a date. var date = new Date() date.getYear() // 122 I plugged this into another object and couldn't understand why it was setting the date to 0122. Like, what significance does 122 years from 1900 even have? Turns out I had to use get Full Year, which is of course perfectly intuitive.
Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great? I would take `format(year(), '/', month(), '/', day())` over ad-hoc format strings by various APIs. Reading the docs further this also stands out: > For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some cent…
I agree. I really like how the `time` crate[0] in the rust world handles this[1]. with your example: > format_description!("[year]/[month]/[day]") 0: https://crates.io/crates/time 1: https://time-rs.github.io/book/api/format-description.html
Ha, I just fixed a similar thing at work right before Christmas. If you use java, consider using google error-prone. It has a check for that (and many other things) https://errorprone.info/bugpattern/MisusedWeekYear
Is there something similar for Python or JavaScript?
Earlier quoted context omitted.
eslint is the de facto standard for Javascript, there may be rules or plugins to check for date formatting rules.
There is no date formatting in JavaScript's standard library. External libraries tend to just fix this kind of thing with a breaking change.
Earlier quoted context omitted.
> Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great? Yes, but it would not have helped with the bug in question. The parallel bug for a strongly typed interface would be "year()" returning this monstrosity, while "iso_year()" or some other poorly named variant returning the expected year. No API is immune to footguns and bad design d…
I forgot how bad JS's date API was until I tried getting the year out of a date. var date = new Date() date.getYear() // 122 I plugged this into another object and couldn't understand why it was setting the date to 0122. Like, what significance does 122 years from 1900 even have? Turns out I had to use get Full Year, which is of course perfectly intuitive.
Even when javascript was written (and likewise with things like perl and php - and of course the underlying function dated back to the 70s ), it was still quite common for people to write dates by hand as 6/6/96 for June 6th 1996, hence people would often write something like
print day() + "/" + mon() + "/" + year()
If you wanted to put a 4 digit year many people
print day() + "/" + mon() + "/19" + year()
After 2000 came round, many sites would claim the year was 19100, I still saw these sites until well into the late 00s
However some people wrote print day() + "/" + mon() + "/" + (1900 + year())
Which would give the correct display.
Changing year() from returning a 2 digit (which in the 80s and even in the 90s was often preferable) to 4 digits would be a breaking change. Changing it to being "the last two digits" rather than "number of years since 1900" would be a breaking change. That's not something that people like to do, hence things like "getFullYear" to return a 4 digit year (or 3 digit for <1000 etc)
IMHO we should be using explicit names in format strings such as `{year}`/`{week_year}` instead of remembering the differences between yyy, yyyy, YYYY and more.
Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great? I would take `format(year(), '/', month(), '/', day())` over ad-hoc format strings by various APIs. Reading the docs further this also stands out: > For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some cent…
Verbose naming, yes, on the other hand would probably have made the situation clearer.
Earlier quoted context omitted.
> Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great? Yes, but it would not have helped with the bug in question. The parallel bug for a strongly typed interface would be "year()" returning this monstrosity, while "iso_year()" or some other poorly named variant returning the expected year. No API is immune to footguns and bad design d…
I forgot how bad JS's date API was until I tried getting the year out of a date. var date = new Date() date.getYear() // 122 I plugged this into another object and couldn't understand why it was setting the date to 0122. Like, what significance does 122 years from 1900 even have? Turns out I had to use get Full Year, which is of course perfectly intuitive.
Earlier quoted context omitted.
I agree. I really like how the `time` crate[0] in the rust world handles this[1]. with your example: > format_description!("[year]/[month]/[day]") 0: https://crates.io/crates/time 1: https://time-rs.github.io/book/api/format-description.html
+1 for strongly typed and compile-time checked, but I'm still not a fan of a sub-language within a string literal. The language already has syntax to structure things, why make a separate language within strings?
I don’t think the language has anything suitable for these purposes. What did you have in mind?