8 ms·
>ALWAYS use timezones with your dates This is bad advice. NEVER use timezones with your dates because there is only one timezone: UTC. Anything else is a prese
by fnord123 7y ago
>ALWAYS use timezones with your dates
This is bad advice. NEVER use timezones with your dates because there is only one timezone: UTC. Anything else is a presentation format.
Of course, if you are in a system that already committed the cardinal sin of storing datetimes with timezones then you have to deal with it. Alas.
- kstenerud 7y agoPlease please please please don't perpetuate this idea that all stored timezones must be UTC. Timezones are always necessary, and while they can often just be UTC, they can't always be [1]. [1] https://technicalsourcery.net/posts/time/ https://technicalsourcery.net/posts/time/
- fnord123 7y agoThat is an interesting post and does discuss the issue of always-local-to-me calendaring and planning future dates when you don't know what the political regime will do with those times in the future. Those are fair points. For recording all events (i.e. times you see in logs, 99.9999% of timestamps you will see), there should only be one timezone: UTC.
- Lendal 7y agoWhat if you're building a $350M machine that weighs many tons, located deep inside a concrete facility and will never ever be moved? The people who operate this machine years in the future will read a date on a log file or database table and make decisions that could affect the lives of millions of people, all of whom live in the same time zone with said machine. I don't want these people to be forced to convert UTC in their heads when there is no reason for it except for some abstract rule created by someone who doesn't know the first thing about this machine and its purpose, or the people who live there.
- fnord123 7y agoIf you have very specific design constraints, please don't use advice from random people on the internet as though it's absolute gospel.
- twic 7y agoI am intrigued by the implied possibility of a project without specific design constraints.
- falsedan 7y agothe design constraint almost 100% matches 'my desktop computer in my house'. please don't vapidly declare some logocentric nonsense and assume people who know better can just ignore your comment.
- lmm 7y ago> The people who operate this machine years in the future will read a date on a log file or database table and make decisions that could affect the lives of millions of people, all of whom live in the same time zone with said machine. They live in the same time zone now. What makes you so sure it will be the same time zone for the lifetime of the machine? More insidiously, what makes you so sure that that timezone's DST rules won't change, leading to timestamps that are correct half the year and then almost, but not quite, correct the other half of the year? Or worse, that are correct for 50 weeks of the year and then out by an hour for 2 weeks a year because the DST change date got moved? Better to use UTC and get those operators in the habit of converting every time.
- pstuart 7y ago> Better to use UTC and have their tools translate at display time FTFY
- icebraining 7y ago> convert UTC in their heads Why would they do that, instead of using the computer to do it?
- pbowyer 7y agoRe his rant on IS0 8601: is there a better format to use, that doesn't hardcode the offset?
- ed312 7y agoThis is bad advice. If you convert the timezone you're now taking on the risk that your conversion was incorrect. You also lose the valuable information of the source time zone. UTC isn't perfect and is _far_ from the only viable timezone for a given domain.
- xwdv 7y agoNope. You shouldn’t be doing your own timezone conversions. If you are storing a time into a database the database should be handling the conversion of your date to UTC. If you care about the original timezone store that elsewhere. Do not make one piece of data serve two different functions.
- dwild 7y ago> If you care about the original timezone store that elsewhere I think that was his point, that you should always care about the original timezone and thus keep it.
- hobs 7y agoSaying "We might have bugs" isnt a good reason to reject a proposal. Generally you store an offset/name of the zone, which then isnt losing the valuable information about the source zone - if you dont do this you are right, this will fall down almost immediately.
- husainalshehhi 7y agoUTC is a timezone. So his advice still stands. He probably meant that you should not use time without knowing the timezone, and UTC is the easiest way to attach timezone to a time instance.
- raxxorrax 7y agoMaybe unpopular opinion: UTC with offset is actually better, because it contains information that might be worthwhile. If I live in 2019-06-19T00:00:00+0200 and save the current time as 2019-06-18T22:00:00Z and don't have any additional information, there could be suddenly dragons...
- kstenerud 7y agoTimezone data should always be the actual timezone, not the offset. Offsets don't take into account the political nature of time. For example, in Europe in 2021, countries will cease to use daylight savings, changing their time offsets permanently.
- simonw 7y agoOnly using UTC makes sense if you are recording exact moments in time - when a log line was generated for example - but it falls over when you start interacting with actual human times. If I say an event is happening at 7pm, I mean 7pm in my local timezone. If I record that upcoming datetime in UTC but I forgot about a daylight savings time change between now and then that doesn't mean the event will happen at 6pm - it's still happening at 7. I've done some projects where I've stored dates as a localtime, a timezone AND a denormalized, calculated UTC datetime (for lookup/sorting).
- simonw 7y agohttps://technicalsourcery.net/posts/time/ https://technicalsourcery.net/posts/time/ says this better than I did.
- treis 7y ago>If I record that upcoming datetime in UTC but I forgot about a daylight savings time change between now and then that doesn't mean the event will happen at 6pm - it's still happening at 7. This breaks down when you start having to deal with multiple timezones. Then whenever you do sorting or availability checks you have to account for DST/timezones. You will pretty quickly make a method that converts your timezone stored data to UTC. Better to just store it all as UTC so that your DB queries are much simpler.
- ubercow13 7y ago>If I record that upcoming datetime in UTC but I forgot about a daylight savings time change between now and then There are good reasons for not storing in UTC but this doesn't seem to be one of them. Surely the problem in this case is just that you incorrectly converted to UTC? It's just a bug.
- mbreese 7y agoDaylight saving time rules can change... Just because you stored it correctly now doesn't mean it is correct in the future (when it's needed).
- forkerenok 7y agoI agree with the sibling, _this_ is also bad advice. It really depends on the use case. For example: * If date is used as a "low precision timestamp", then I'd advise to use full timestamp+tz and extract the date in presentation after applying tz adjustments. * Sometimes date represents a sort of a fiscal date, which refers to a time period that captures business hours in a certain location. There it is a bit trickier, but slamming a tz on it is not an answer. As for timestamps, stick to UTC if you can, but in any case keep TZ explicit. There are two many middlewares there that would be happy to assume a tz for you and give you hell.
- wvenable 7y agoIf your application is future-dating items, like say clients entering appointments in a calendar, this will be very wrong. If a customer enters an appointment 6 months in the future, it will end up at the wrong time due to daylight savings time. UTC is great for timestamps (when did this event happen) but not good for user-entered dates. You throw away useful information if you store in UTC.
- deleted 7y ago[deleted]
- wil421 7y agoYou store the offset or you store the users configuration. Use the users config and/or offset to convert it from UTC. There should be a way to account for DST. I’ll look into it when I get a chance. If the future date was input in EDT or EST you’d know what to do in the future when you convert back to either EDT or EST based on the time of year.
- wvenable 7y agoYou can do a lot of things but, at some point, you have to ask yourself if the solution is signficantly more complex than storing local time and the timezone. You also need to be aware that timezones change; even now there are discussions about eliminating daylight saving time in various regions. If you store 4:00pm on Nov 25th and convert that to UTC based on the timezone rules as they exist today, you'll be wrong when you convert them back under different timezone rules. There's just no way to do that cleanly. There are also things to consider: if the user changes their own timezone (by moving) did they intend the value of that time to change (4:00pm is now 1:00pm because it's a WebEx and they moved East) or did they intend that to remain at 4:00pm (it's when they take their medicine every day).
- dragonwriter 7y ago> If your application is future-dating items, like say clients entering appointments in a calendar, this will be very wrong. Well, the future has problems no matter what you do. > If a customer enters an appointment 6 months in the future, it will end up at the wrong time due to daylight savings time. No, becauae that you store UTC doesn't mean that you also convert entries to UTC using the offset on the entry date without looking at the date the time is attached to. OTOH, no matter what you store, the fact that DST rules and even timezone boundaries can change over time means that you have to store a lot more about the intent than just the time to be certain of being correct for future times. Did you want X time in Y time zone or X time in the legal time applicable to Z venue? The former is often used as a proxy forthe latter on the assumption that tim zones don't change...
- gpvos 7y agoNo. UTC-only is only good for log files. In all other cases, you should store a timezone offset with your dates.
- java-man 7y agofnord123, you are confusing Instant with ZonedDateTime (to use java classes as an example). An instant is a moment in time, expressed in java as milliseconds in UTC. A ZonedDateTime (if we ignore time portion of it for the sake of brevity) is a LocalDate (year-month-day) with a time zone. One can convert an instant to LocalDate given the time zone, or vice versa. But one cannot convert between the two if the time zone is missing. So, time zone is not a presentation format, it's an essential part of the data. One can, of course, store a LocalDate in a database, iff the timezone is somehow assumed (and hit the land mine when the assumption is violated by a recent change).
- zip1234 7y agoThis is very much not true. There are good cases for both. John Skeet, who knows more about this topic than anybody I can think of, wrote a blog post that explained it well: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
- fnord123 7y agoThat's a very well written post. Thanks for sharing it.
- jmcqk6 7y agoIn addition to the other replies, I defer to the great Jon Skeet: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
- misja 7y agoApparently I'm in the minority together with OP but I agree that storing dates as UTC is good advice. What most repliers seem to have overlooked is that OP is saying that timezones should be used for presentation. Maybe it was not clear, but that also means they should be used for input conversion. But once the dates have to be used by the business logic of your system, you really want to prevent the headaches you will get when you have to deal with timezone transformations everywhere. That really adds a ton of complexity, is easy to overlook and above all an error in timezone conversion can go undetected for a long time.
- beckler 7y agoI don't think anyone is saying that you shouldn't store datetimes in UTC. It's just that time is complex and the errors can be subtle, and you don't want to mess up appointments across timezones because you didn't factor in the timezone when appointment was originally made. http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html http://www.creativedeletion.com/2015/03/19/persisting_future...
- mikeadams2014 7y agoIs there ever a reason to not just use unix epoc time? (besides the year 2038 problem https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem)
- karmakaze 7y agoDon't dogmatically choose either. I had one case where it made sense not to use UTC but was hard to get across to those who were stuck on ALWAYS. The case was for photos taken around the world on a photo site. Each photo effectively has a place and time at that place. Storing UTC would have shown NYE midnight pictures at an arbitrary hour based on viewers tz.
- koyote 7y agoI'd argue that in that case you store two values: 1. The time the photo was taken in UTC (as usual). 2. The UTC offset for the photo location.
- mceachen 7y agoI banged my head on this several times until I came up with basically the same conclusion. PhotoStructure stores both the raw EXIF value, a nullable timezone that tries to adopt sibling's timezones (normally only inferable when you have GPS tags, including GPS acquisition time, which is always in UTC). It also stores the source of the inference, so other heuristics know how much it can "trust" that value. I open-sourced the GPS location and offset inference code: https://github.com/photostructure/exiftool-vendored.js https://github.com/photostructure/exiftool-vendored.js
- karmakaze 7y agoOthers before tried just that. Photo métadata is notoriously inconsistent and incomplete. You're much more likely to have accurate local time and not much else.