DateTime ISO 8601 Format
-
First of all my apologies if this is in the wrong forum, i'm sure i will find out very quickly if it is :doh: So basically i am writing an API that needs to return the running date and time of tours including the offset, this format "2016-12-05T10:00:00+02:00", these tours can be in England or Italy so they run in two different timezones and should have a different offset. Our API and DB run on servers in the US, all the running times are stored in the db as a datetime, without any offset, without anything to distinguish the timezones they run in bar the fact they are linked to different countries. I'm just wondering what the coorect process is here, i have spent ages reading up on this and i think I'm more confused than when i started. I am thinking that maybe i need to get the running date as a universal datetime and decrease this datetime for the English tours but i'm not sure how i can update the date to have a different offset, how to set/change the date so it knows its in a different timezone. Any guidance, advice or suggestions of an appropriate blog/article to put me on the correct track would really be appreciated, thanks very much in advance.
-
First of all my apologies if this is in the wrong forum, i'm sure i will find out very quickly if it is :doh: So basically i am writing an API that needs to return the running date and time of tours including the offset, this format "2016-12-05T10:00:00+02:00", these tours can be in England or Italy so they run in two different timezones and should have a different offset. Our API and DB run on servers in the US, all the running times are stored in the db as a datetime, without any offset, without anything to distinguish the timezones they run in bar the fact they are linked to different countries. I'm just wondering what the coorect process is here, i have spent ages reading up on this and i think I'm more confused than when i started. I am thinking that maybe i need to get the running date as a universal datetime and decrease this datetime for the English tours but i'm not sure how i can update the date to have a different offset, how to set/change the date so it knows its in a different timezone. Any guidance, advice or suggestions of an appropriate blog/article to put me on the correct track would really be appreciated, thanks very much in advance.
IMO, you are mixing two issues, one being the storage of the time and the other being the display. Dates and times should always be stored using a common base (e.g. UTC). The exact base is irrelevant (it could just as easily be Eastern Standard Time), but it should be consistent. The display may depend on the location of the user (e.g. all the DB users are in the U.S.), the location of the tour (display in UK time or Italian time), etc. For example, airline schedules are always displayed using the local time at the origin (for takeoff) and at the destination (for landing). I hope this helps.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
IMO, you are mixing two issues, one being the storage of the time and the other being the display. Dates and times should always be stored using a common base (e.g. UTC). The exact base is irrelevant (it could just as easily be Eastern Standard Time), but it should be consistent. The display may depend on the location of the user (e.g. all the DB users are in the U.S.), the location of the tour (display in UK time or Italian time), etc. For example, airline schedules are always displayed using the local time at the origin (for takeoff) and at the destination (for landing). I hope this helps.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
:thumbsup:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
IMO, you are mixing two issues, one being the storage of the time and the other being the display. Dates and times should always be stored using a common base (e.g. UTC). The exact base is irrelevant (it could just as easily be Eastern Standard Time), but it should be consistent. The display may depend on the location of the user (e.g. all the DB users are in the U.S.), the location of the tour (display in UK time or Italian time), etc. For example, airline schedules are always displayed using the local time at the origin (for takeoff) and at the destination (for landing). I hope this helps.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
Daniel Pfeffer wrote:
Dates and times should always be stored using a common base (e.g. UTC). The exact base is irrelevant (it could just as easily be Eastern Standard Time), but it should be consistent.
Spot on! :thumbsup: /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
IMO, you are mixing two issues, one being the storage of the time and the other being the display. Dates and times should always be stored using a common base (e.g. UTC). The exact base is irrelevant (it could just as easily be Eastern Standard Time), but it should be consistent. The display may depend on the location of the user (e.g. all the DB users are in the U.S.), the location of the tour (display in UK time or Italian time), etc. For example, airline schedules are always displayed using the local time at the origin (for takeoff) and at the destination (for landing). I hope this helps.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
Thanks for your reply, much appreciated. So based on your logic could I not say that all my times are stored in Italian time but not in UTC, then try to convert them to UTC and back to the English time just for the tours in England?
Yes, that would work. The advantage of using UTC for everything is that you don't need to handle switches between Daylight Saving Time and Standard Time - UTC has no Daylight Saving time. It also simplifies your code - all display times require one (and only one) conversion. Compare and contrast to the Italian --> UK case.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
