Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Because Java is super old. I remember starting with Java 1.2 back in 2000. For over a decade it also tried to really push for backwards compatibility, and didn't end up with breaking changes until Java 9.
Joda time was used to fill in a gap on how bad the original Java date times were. Eventually a very of that became a part of the language.
So it's due to a lot of legacy stuff. Swift is incredibly new by comparison. -
Because they're old. The ways dates have been handled by programmers have changed so many times after learning from mistakes.
It's complicated to handle because time IS a complicated matter (e.g. https://gist.github.com/timvisee/...).
C# and Java don't have multiple types and ways that handle time. They have ONE way and a bunch of outdated and deprecated ones. -
Plus, not having a way to handle timezones is NOT a strength... No idea why you'd give that as an example of a good date system.
I don't know Swift but it sounds hard to believe it's dates can't handle timezones, but if it's actually true, than it's a huge downside.
Congradulations, you now can't use the language to do any network stuff or logging stuff or database stuff or etc' -
@SoldierOfCode Swift can absolutely handle timezones.
The difference is that the concept of time zones is not tied to the Date type.
Time zones are handled in the process of formatting/parsing in a DateFormatter because that’s the correct place and time to do so, not in the Date type itself.
Think about it, there is no inherent time zone in a given point in time. Time zones are relevant in the context of presentation (like in the UI), where you can provide the user’s region and preferred format. And it’s relevant in the transportation of that point in time, such as via a REST api, where you can specify to agree on UTC or GMT. -
I forgot about how complicated it was to work with Dates when I was a C# dev after working with Swift for a decade or so.
Now Kotlin is reminding me again.
It really makes me appreciate the great design of Swift's standard lib, which it inherited from Objective-C, as I said.
Leaves me wondering why it hasn’t been copied by its competitors.
Probably because of "eww, Apple" 😒
Found this in our codebase, apparently one of my co-workers had written this
Why the hell do languages like Kotlin (Java) and C# handle dates and datetimes so needlessly complicated?
There are multiple types with different implementations and concepts like local time or time zones represented by those types. Some of them have capabilities like serialization, some of them don’t.
Parsing and encoding is tied to the types.
Why? Take Swift as an example:
It has one single Date type (including time) which represents a point in time independent of any calendar, time zone, encoding or format.
There is a DateFormatter to parse from APIs from iso or timestamps or whatever and to format to UI as a string in any language (localization), for any region, in any format.
If you just want a container for the date time components themselves (which the concept of local date time seems to be in those languages), you can use the DateComponents type. If you are interested in dates from the perspective of a calendar, there is a Calendar type.
Everything makes sense and the different concepts are decoupled from each other as they should be.
Damn! My memory about C# is a bit hazy but Kotlin, I’m disappointed in you! Date handling is a horrible mess!
Ok, I guess I can blame it on Java and JVM.
rant
kotlin
date
time
wtf