TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

All about java.util.Date

195 点作者 D_Guidi大约 8 年前

17 条评论

hn_throwaway_99大约 8 年前
I think the article gets at this, but the biggest &quot;eureka&quot; I had was when I realized that java.util.Date is <i>just</i> sugar around a long value (ms since the epoch). Thus, wherever you use a Date, if you would NOT consider using a long there, then Date is the wrong choice. E.g. timestamp for log entry records - yeah, makes sense. Days on a schedule app - definitely wrong choice.<p>Of course, as the article and other commenters have said, just use jodatime or the Java 8 equivalent.
评论 #14180837 未加载
评论 #14182227 未加载
评论 #14182102 未加载
Clownshoesms大约 8 年前
I&#x27;ll never understand why they thought 0-based months made sense, but then used 1-based days and 1900-based years. Even if C did it. Almost feel like I can hear the committee:<p>&quot;Meh it&#x27;s only a Date class, no one will really use it, will they? Billy already committed the code for 0-based months. Who here does <i>not</i> think of January as month zero?&quot;<p><i>feet nervously scuffing carpet</i><p>&quot;Right, settled! Moving on, company picnic is on the 1st of 0 next year (96)&quot;.
评论 #14180723 未加载
评论 #14183499 未加载
评论 #14182694 未加载
bloat大约 8 年前
<i>How do I convert a Date to a different time zone? You don’t – because a Date doesn’t have a time zone.</i><p>There&#x27;s something about this, and the way we think about dates, which makes it very hard for some people to understand. Some people get it immediately, others never will. Not wanting to sound superior (I think the Date object seems almost designed to foster this confusion), but I&#x27;ve lost count of the number of times I&#x27;ve spent a long time explaining this, and then at the end of it all the person still says something like, &quot;OK, well we&#x27;ll just use this GMT Date then.&quot;
评论 #14180305 未加载
评论 #14183027 未加载
评论 #14181942 未加载
评论 #14180618 未加载
评论 #14180709 未加载
评论 #14180271 未加载
评论 #14180711 未加载
ddlatham大约 8 年前
<i>So how do computers represent instants? They typically store an amount of time before or after a particular instant which is effectively an origin. Many systems use the Unix epoch, which is the instant represented in the Gregorian calendar in UTC as midnight at the start of January 1st 1970. That doesn’t mean the epoch is inherently “in” UTC – the Unix epoch could equally well be defined as “the instant at which it was 7pm on December 31st 1969 in New York”.</i><p>A thousand times yes. I see many developers confused by this. The Unix epoch is not inherently specific to UTC, it just happens to have a round date when described in that time zone. Seconds (or milliseconds) since the Unix epoch is a unit <i>without timezone</i>.
评论 #14181618 未加载
alblue大约 8 年前
Several years ago I answered a question on StackOverflow &quot;what&#x27;s wrong with the date and time api in Java&quot;<p><a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1969442&#x2F;whats-wrong-with-java-date-time-api&#x2F;1969651#1969651" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1969442&#x2F;whats-wrong-with-...</a><p>Considering how long ago it was answered, it took a &#x2F;long&#x2F; time for the Java 8 replacement to come on board and give some sanity back to Java date computations.
评论 #14181630 未加载
RegW大约 8 年前
For many years my advice to other java devs has been to avoid using java.util.Date and Oracle date columns where possible - for all the reasons given in the article, but generally because they don&#x27;t always do what you expect.<p>The reason is that these dates encapsulates one concept of date (a point in time), and devs often try to use it for another (the legal date).<p>A legal date is fixed. It also has no time zone, but in a different way - it will not look different when viewed from another timezone. I was born on the opposite side of the world to where I live. The DOB on my passport didn&#x27;t change, as I moved around the world.<p>Too often the user inputs a legal date. Software translates this to a point in time so it can be stored in one of these dates, the TZ info is lost, and before you know it the software is displaying a date other than that input. A bug is filed, a dev investigates and hacks code to add one hour, the bug is closed, and another opened when we pass into daylight saving.<p>It doesn&#x27;t have to be like this - even MS Excel knows to just use a day count.
评论 #14183769 未加载
BurningFrog大约 8 年前
The misleading name is the worst misfeature. I&#x27;ve had to explain to at least half a dozen coworkers that Date is not a date, but a timestamp. Some people just refuse to believe it, perhaps because they trust the Java designers more than me, as you normally should.<p>Often they persist in thinking &quot;it&#x27;s just a more detailed date, 17:08, April 23 is still April 23&quot;.<p>Then I have to explain that every Date object is on two different real dates. That&#x27;s a <i>big</i> struggle for many.
pducks32大约 8 年前
This confused me with Foundation&#x27;s Date class as well. I think it&#x27;s really important to have abstractions that are really clear. Like for example I had to represent Open Hours for business and wanted a way to represent 4pm on Monday. That&#x27;s surprisingly hard (in Swift and Java) because the APIs want you to realize the complexity of Time. But I don&#x27;t care. I want an abstraction that says &quot;Yup it&#x27;s Monday at 4pm in Santa Clara&quot;. I think better Date and Time libraries that deal with more user facing things would be great.
评论 #14180979 未加载
评论 #14181019 未加载
TeMPOraL大约 8 年前
Tangential, but one of the best sources I&#x27;ve seen on issues with times and dates is Eric Naggum&#x27;s &quot;The Long, Painful History of Time&quot;.<p><a href="http:&#x2F;&#x2F;naggum.no&#x2F;lugm-time.html" rel="nofollow">http:&#x2F;&#x2F;naggum.no&#x2F;lugm-time.html</a><p>Notably, besides outlining the complexity of the domain, the article also serves as explanation of decisions made by author in implementing local-time, a popular date&#x2F;time library for Common Lisp.
adrianmonk大约 8 年前
<i>It doesn’t have a calendar system.</i><p>Hopefully this won&#x27;t come off as mere quibbling about terminology, but to me it makes more sense to say that it <i>does</i> have a calendar system, it&#x27;s just that it isn&#x27;t any of the ones humans use. When I write &quot;April 23, 2017 6:04pm CDT&quot;, the calendar system is Gregorian. If I were to write the integer value underlying a java.util.Date, I would argue the calendar system is Unix Epoch.<p>Both are systems that pick out arbitrary points in history (year 1 AD or midnight January 1, 1970) to base numbers off of. Both have rules on how you manipulate those numbers and what values mean.<p>If someone persists in asking what the time zone is for a java.util.Date, I would probably tell them that, more or less, it has <i>its own</i> time zone. This isn&#x27;t quite true, but it&#x27;s close because time zones are basically parameters for parameterized calendar types, so a time zone kind of implies a calendar.<p>Anyway, the point is that thinking of it as its own calendar system hopefully makes it clear that it stands on its own.
评论 #14181456 未加载
AlexTelon大约 8 年前
Javascript seems to have many (if not all) of the same issues. I learnt this firsthand a while ago when I knew nothing about these issues and just assumed that getting the Date of a particular time instant would be an easy task. See rant below:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;jonhoo&#x2F;wp2ghost&#x2F;pull&#x2F;8#discussion_r84797728" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jonhoo&#x2F;wp2ghost&#x2F;pull&#x2F;8#discussion_r847977...</a>
funwithjustin大约 8 年前
One similar thing that&#x27;s always bothered me conventionally. Why is it `System.arraycopy()` and not `System.arrayCopy()`?
评论 #14182535 未加载
sandGorgon大约 8 年前
The discussion around monotonic time in golang is one of the most indepth discussion around time handling that I ever saw. Not sure if java covers all these scenarios.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;12914" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;12914</a>
nl大约 8 年前
The story I&#x27;ve heard was the java.util.Date was written by an intern at Sun.<p>I think that would explain a lot.
评论 #14183666 未加载
lsd5you大约 8 年前
A relic of 90s programming. Perhaps we can take a moment to realise we are not just doomed to reinvent things that were done properly in the 70s. Looking back there were plenty of things that were just poorly thought out and this was one of them.
评论 #14181494 未加载
nottorp大约 8 年前
While the content is spot on, I disagree about the title - it&#x27;s more of an introduction than an &#x27;all about&#x27;. You understand it best if you already know how to (not) use java.util.Date...
shouldbworking大约 8 年前
TLDR: It sucks balls use Jodatime<p>Edit: I was wrong my bad
评论 #14180390 未加载
评论 #14180383 未加载
评论 #14180389 未加载
评论 #14180404 未加载