4 ms·
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
by rusk 10y ago
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.
- distances 10y agoI 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.
- yen223 10y agoUnless 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.
- distances 10y agoYes, I'm sure the use cases I've had to deal with have been very simple to start with.
- TheCoelacanth 10y agoThat 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.
- BurningFrog 10y agoThat works, but note that it's different from using java.util.Date, which is not in UTC or any other time zone.
- rocqua 10y agoNot 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.
- rusk 10y agoExcellent 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.