Hacker News Reader

Comment by bloat | Hacker News Reader

How do I convert a Date to a different time zone? You don’t – because a Date doesn’t have a time zone.

There'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've lost count of the number of times I've spent a long time explaining this, and then at the end of it all the person still says something like, "OK, well we'll just use this GMT Date then."

View on HN

Computerphile has a wonderful video about dates that covers this subject perfectly. Mandatory viewing on my team before anybody has a problem involving dates.

https://m.youtube.com/watch?v=-5wpm-gesOY

For me, the moment the penny dropped was the realisation that "Timezone" is a presentation layer issue. i.e. it's not something you should concern yourself with until you're rendering it to be read by a human. Otherwise just using some well-defined simple convention such as epoch-time is fine throughout your application. There are exceptions such as doing date-calculations and such, but I extend my rule of thumb such that these kinds of things should be converting from epoch time (e.g. to `Calendar`) for the calculation and then back again.

I agree, I find it a well working convention to use UTC times for everything in an app, and convert to local time zone only at the time of display when formatting the date as a string.

Unless you are dealing with recurring events that happen at a specific time of day, in which case you need to know the local timezone to avoid off-by-one-hour errors if daylight savings kicks in.

Yes, I'm sure the use cases I've had to deal with have been very simple to start with.

That works for some things, but not for others. If I set my alarm clock to 7 AM local time, you convert that to UTC, then I travel one time zone over and you wake me up at 8 AM local time, I'm going to be annoyed.

That works, but note that it's different from using java.util.Date, which is not in UTC or any other time zone.

Not quite though. If you have a calendar app, and someone has an appointment for 1 Jan 2018 14:00 LTM (LTM being a zone I just made up). Now suppose than in the next year, the LTM timezone changes. This sometimes happens to ease international commerce.

In the case of such a change, I'd argue the time-instant should change and the timezone representation should be constant.

Excellent corner case. Here it comes down to how you model the storage of your appointments. Since the issue is framed within a calendar the "instant" itself is not of primary concern, but the position within that calendar.

This is also how the likes of "chron" model scheduling of tasks. I found this so hard to wrap my head around at first precisely because I was used to dealing with time "as a programmer" from the inside out. Of course when you're scheduling a repeating task that you want to happen "at midnight" or "on a Monday morning" it makes more sense to specify in this top-down manner.

I might categorise such things as "a presentation layer" concern, but as you point out, in these cases your moment in time is stored as a calendar reference.

C++'s equivalent is std::chrono::time_point, which seems like a much better name. A "point in time" is not obviously something a time zone would be attached to.

> Some people get it immediately, others never will.

Member of the second camp reporting in. The default toString() behavior of java.util.Date threw me off for a very, very long time.

Whether a Date includes the time zone is an arbitrary convention, and unfortunately some people intuitively gravitate towards one or the other.

You can say that a Date doesn't include a time zone, but then a Date no longer actually refers to a concrete time -- it needs to be combined with a time zone first. This differs from how conventional language deals with dates, which is why people don't like it. And also the point of the article -- Java's Date class is misnamed and confusing.

No, that’s exactly the parent’s point. Date always refers to a single concrete point in time, a time zone is only needed when parsing the date or formatting it for output.

An offset from a certain point in time without a time zone might be better described as an abstract point in time? Given such Date-s A, B, C you could order them (with potential overlap) and talk about how far apart they were) - but would need to convert via the help of a timezone to get a concrete point in time?

It appears that you still think of a date without a time zone as relative, which isn’t right (IMHO). A Unix date is an absolute mark on the axis of time, time zones are just different “views” on this time.

What really helped me get this is the distinction between GMT and UTC.

UTC is a universal method to describe time-instant. However, UTC is not a timezone. GMT is a timezone, specifically, it is the timezone GMT+0. Representing a time-instant in GMT for universality is wrong, representing a date (i.e. the kind of thing humans use to denote appointments in their daily life) in UTC is also wrong. Use the construct that matches the domain.

I think it is a matter of perspective. Say we take Planck time to be the atomic unit of time. Then really any larger unit of time can be viewed as interval of time with some error bounds. One you reach time units of on the scale of "days", time zones definitely impact this interval. Saying something happen(s/ed) on a particular day is not precise because a day is just a particular interval of time that varies based upon your time zone.

This is why if you've ever submitted a paper to a conference, the deadline will nearly always be given with an hour level of precision and a time zone. Because just saying submissions are due on day X is not well defined in the modern world.

Edited: Not sure why this is getting downvoted. Do you people seriously believe that 4/23 is the same period of time in NYC as it is in London?

From the HN guidelines:

Please resist commenting about being downvoted. It never does any good, and it makes boring reading.

Can we get an addendum to please resist quoting the guidelines? That is definitely boring reading.

I actually enjoy it.

> Do you people seriously believe that 4/23 is the same period of time in NYC as it is in London?

Honestly, it sounds like you didn't read the article and/or you misunderstood grandparent comment.

The Date class in Java does not represent a calendar date or period of time like "April 23th 2017". It represents an instant in time. It is precise to the millisecond and it does not depend on a specific time zone -- although it can be represented in different time zones. If you give the same (Java) Date value to a bunch of of people around the world and tell them to hook up to your live chat at that date and time, they will be able to attend at that time with no further information (such as timezone).

I think trurl's comment actually serves to highlight how awful java.util.Date's design is, and how important names are in programming. trurl was responding to a comment about Date not having a timezones, on an article that goes in depth as to how Date just represents an instant in time and not a date on a calendar, and he still misunderstood what java.util.Date's represent. Imagine how the legions of programmers new to Java make the same mistake.

I don't see anything in trurl's comment that makes any reference to java.util.Date. A more charitable reading would be to assume he is discussing the abstract concept of a date as it was mentioned upthread.

Reply on news.ycombinator.com