As with cryptography, don't attempt to write your own date/time code. You will get it wrong. Use the datatypes and library functions in your language or database.
For many operations the Kalends library actually converts to UTC (and UTC is almost the same as epoch). For instance to calculate the amount of seconds between two datetimes.
Your advice might work in a lot of cases, but if you have a good datetime library you should not need to IMO. But I am sorry to say that I do not think most datetime libraries are very good when it comes to timezones.
You don't have to manually say: oh this datetime is not UTC, I better convert it as soon as possible. If you need to save a future datatime which is not UTC, it is actually error prone to convert to UTC.
What Kalends does instead is to have a struct with an unambiguous, validated datetime and the timezone along with it.
That way, if for instance you are dealing with a datetime entered by a user, you have the actual datetime entered, but you still have all information you need to convert to UTC.
It's less ambiguous but it's not 100% unambiguous because future policies of Daylight Saving Time and Time Zone / Time offset boundaries can be changed by governments.
Even if the struct had extra fields for flags such as "obey future DST changes" or "ignore present TZ if different from historic TZ at time of data entry", it's still ambiguous if geographic coordinates are not embedded within the struct. Then again, there's probably some more edge cases even with latitude/longitude coordinates. (E.g. should the future time be interpreted at lat/long of where he data-entered the datetime, or the lat/long of where he later experiences the datetime?!)
Dates specifying future events are very tricky++. Unless, it's a future date for something celestial such as a solar eclipse; in such cases, a future date as UTC is unambiguous.
++Because we all conflate concepts of "socially-constructed future datetime as shown on a wall clock" and "scientific future datetime". We stuff both concepts into the same data structures. Nevertheless, we write software that makes educated guesses about the user intentions for "future dates" and it works for 99% of the typical use cases. (e.g. "send smartphone notification for 12:30 lunch with Bob next week.)
To use an Epoch you have to convert it into a timezone aware date (as you stated, as late as possible). Now that could be UTC but more likley it will be a timeZone that observes a daylight savings time.
Consider the epoch of 0, 1st of Jan 1970 or what ever it is. Well that's correct in GMT but if you are in NYC what time is it, how about Singapore, Australia, Huston etc...
A.) Convert it to Utc.
B.) Show it to someone.
Got some 'splain'n to do if I catch non-utc manipulation or comparison going on in my code bases. And heaven help you should you stick a non-utc time into the database.
I will stick non-UTC time into the database and I made a library to do it.
An american friend with french heritage noticed happily after moving to germany that the accent de gue on his last name was finally printed correctly on his mail and packages.
All apps I'm building now has a US-audience which means that they have to be timezone aware per default as opposed to apps with a danish audience where I didn't have to be concerned about timezones. The truth is, timezones are a pain.
http://en.wikipedia.org/wiki/UTC%2B00:20
> The exact timezone was GMT +0h 19m 32.13s until March 17, 1937...
Yes, 32.13 seconds.
https://www.timeanddate.com/worldclock/canada/fort-st-john
I have to communicate to my peers that we live in Arizona because Windows doesn't have anything.
Time is not just calendar apps, or cron. Consider relative dates in historical studies that span past, present and future.
Study the fuck out of your use case, get it right, don't worry about others' opinions and don't think that your solution applies generally to most other use cases.
Also, among the many resources for general and specific solutions to time problems is "Calendrical Calculations," by Dershowitz and Reingold. I found it randomly, bought it on a lark, and hope to $DEITY I never haver to care about time for anything critical.
http://www.worldcat.org/search?qt=worldcat_org_all&q=calendr...
Bought it on a lark??
Well, the link I provided was to a worldwide library catalog, you should be able to interlibrary loan it to your branch if you're interested.
Or you can get a copy on Abe Books for pretty cheap.
http://www.abebooks.com/servlet/SearchResults?sts=t&tn=Calen...
But no, my upper lark limit is considerably lower than $265.90. :)
1. If someone leaves Vancouver at 1 am and arrives in Seattle at 4 am on the same day, and you know the distance they travelled is 240 km, what was their average rate of speed? (Correct answer: 120 km/h, 80 km/h, or 60 km/h, depending on what day it is. UTC storage helps here.)
2. If it's noon in Vancouver, what time is it in London, England? (Correct answer: 7 pm, 8 pm, or 9 pm, depending on what day it is. Knowledge of regional DST schedule differences helps here.)
It's my experience that when the programmers get date math correct, they may still find themselves fielding "bug" reports from enterprise customers who should understand the concept but don't (particularly if their business is billing or rate calculation -- think of short term billing for hourly parking or CPU hours as an example).
Especially when, for most of the year, even the US west coast doesn't use PST (they use PDT).
You may think I'm being pedantic, but most naive timezone conversion tools won't pick up this error for you, if you ask them to convert "1PM in PST to my local time". I once ended up on a conference call at the right time by myself because the other party assumed that London time was the same as UTC (it's not - they were in Daylight Saving Time, so they were an hour ahead).
On Debian: http://debian-handbook.info/browse/stable/sect.task-scheduli...
So when discussing whole timestamp or time - everybody is somewhat aware there is going to be timezone involved.
Good luck however, if you need to ask the question: "Is the instruction date (yyyy-mm-dd) in the Counterparty (Sidney), Party (London) or System timezone (Brussels) ?"
You have to think about what the user want's to enter and what they want to see. It's especially hard if they are doing something like booking a flight, or car hire in another country, how do you know if they are thinking about local time or destination time?
Just be careful about generalizing too much and assuming things such as: "this time will exist again tomorrow". Or "next month also has a 31st day". Or "DST is always a 3600 second difference from standard time".
Here is another article I wrote which also talks about some pitfalls of time and timezones: http://www.creativedeletion.com/2015/01/28/falsehoods-progra...
I reciently had a huge issue trying to explain to people why we couldn't (easily) show the offset next to the city on a date time input, because we didn't have a native library to do it. They couldn't grasp that a date in the future could have a different offset for the same city and that they didn't all change at the same time.
If anyone is using JS checkout moment.js and also be aware that date objects in most client side runtimes are in the users timezone by default, and often doen't let you change the offset.
Don't forget that for a lot of applications your users don't care about time zones. "I have a meeting every Monday morning at 10:00AM and some folks from around the world call in". Its up the the programmer to figure that out for all involved.
