WoW:API GetGameTime - Revision history

Move page script: Move page script moved page API GetGameTime to WoW:API GetGameTime without leaving a redirect

2023-08-15T04:45:56Z

Move page script moved page API GetGameTime to API GetGameTime without leaving a redirect

← Older revision

Revision as of 04:45, 15 August 2023

Bear at 22:20, 11 July 2017

2017-07-11T22:20:12Z

Show changes

WoWWiki>Fandyllic: amazing amounts of misspellings; NPOV changes

2017-07-11T17:38:00Z

amazing amounts of misspellings; NPOV changes

← Older revision		Revision as of 17:38, 11 July 2017
Line 2:		Line 2:
	Returns the current server time in hours and minutes		Returns the current server time in hours and minutes
	hours,minutes = GetGameTime();		hours,minutes = GetGameTime();
	==Parameters==		== Parameters ==
	===Returns===		=== Returns ===
	:;hours : Number - The current hour (0-23).		:;hours : Number - The current hour (0-23).
	:;minutes : Number - The minutes passed in the current hour (0-59).		:;minutes : Number - The minutes passed in the current hour (0-59).

	==Example==		== Example ==
	local hour,minute = GetGameTime();		local hour,minute = GetGameTime();
	message(hour .. ":" .. minute);		message(hour .. ":" .. minute);

	===Result===		=== Result ===
	A message with the current server time appears.		A message with the current server time appears.

	==Notes==		== Notes ==
	This function can unexpectedly return results ~~inconsistant~~ with actual realm sever time. The value returned is from the physical instance server you are actually playing on, and not that of the world instance server (realm server) you log into. Servers for instances such as for raids and ~~pvp~~ are often shared between login world servers. And instance servers are not always running using the same timezone as the login realm server. This is ~~particualry noticable~~ for Oceanic and other low population world servers. See below for more...		This function can unexpectedly return results inconsistent with actual realm sever time. The value returned is from the physical instance server you are actually playing on, and not that of the world instance server (realm server) you log into. Servers for instances such as for raids and PvP are often shared between login world servers. And instance servers are not always running using the same timezone as the login realm server. This is particularly noticeable for Oceanic and other low population world servers. See below for more...

	To use this in a macro:		To use this in a macro:
Line 21:		Line 21:


	==~~More notes~~==		=== Server and client time complexity ===
			So for example you log into US Ysera EST at 18:00, and enter Ulduar running on an instance server that is PST. Suddenly the time returned will be 3 hours behind the time you were getting. Confusing but important :) Please keep this in mind if using this time for anything important functionally, such as diffing times or using as part of functional historical data.

	~~So for example~~ you log into ~~US Ysera EST at 18:00~~, and ~~enter Ulduar runing on an~~ instance server ~~that~~ is ~~PST. Suddenly~~ the ~~time returned will be 3 hours behind~~ the ~~time~~ you ~~were getting~~. ~~Confusing but important :) Please keep this in mind if using this~~ time for ~~anything~~ important ~~functionally, such as diffing times or using as part of functional historical data~~.		For getting consistent times you have two basic choices use server or use local client time. Server time is good because all players in a realm will have the same time within more or less a minute accuracy (difference between two clients can exceed a minute [disregarding hours]). Client time is good because you have second precision, but everyone's times are different, as not only do people log into realm servers from other timezones, but you also have no idea how correct their local time is, from unset clocks to bad user timezone, and lots of variance. The "instance server not same time as login server" problem suddenly makes the server time much less valuable for consistency. Two reasons: even if the server is in the same timezone as the login server, you might have variance between the two server like 5-10 minutes, though not typically the case. Using local time for most apps where a universal time isn't important is the way to go.

	~~For getting consistant~~ times you ~~have two basic choices~~ use server or ~~use local client~~ time. ~~Server~~ time is ~~good~~ because ~~all players in a realm will have~~ the ~~same~~ time ~~within more or less~~ a ~~mintue~~ accuracy ~~(difference between two~~ clients ~~can exceed~~ a minute ~~[disregarding hours])~~. ~~Client~~ time ~~is good because you have second precision~~, ~~but everyones times are different, as~~ not ~~only do people log into realm servers from other timezones~~, ~~but you also have no idea~~ how ~~correct their local~~ time is~~, from unset clocks~~ to ~~bad user timezone~~, ~~and lots~~ of ~~variance~~. ~~The "~~instance server ~~not same time as login~~ server" ~~problem suddenly makes the server time much less valuable for consistancy~~. ~~Two reasons: even if~~ the ~~server is in~~ the ~~same timezone as~~ the ~~login~~ server~~, you might have variance between~~ the ~~two server like 5-10 mintues~~, ~~though not typicaly the case. Using local time for most apps~~ where a ~~univeral time isnt important is the way to go~~.		A third choice for consistent times is to mix the two and run a timer correction update event in the background, where you get a base time difference between local and server time as to correct local time to server time, and base seconds (plus diff) purely off of local time. So: seed base → use local time + base as time value in AddOn (server time with second precision) → continue every fraction of second or so to see if server time has rolled over to next minute → reconcile and update base → and on and on... The update event basically corrects the base difference over time to keep it accurate with server time. The base correction update is necessary because users computers can drift dramatically depending on the computer, and because users can choose to change their timezone or clock at any time. Also doing time diffs and adds is not as simple as it sounds; its a bit contrived to get it right. What you end up with however is as near second accuracy universal server time across all clients. This depends on how accurate minute rollovers form server time are and using the clients seconds counter should not drift any perceptible amount inside a minute. The guess is the WoW client itself is basing the server time minute rollovers on local client time as well, just not shared with us through this function, and how often or what triggers actual server time updates to the client is not known. But in practice it has observed this working very very well. However... with the newer problem (the original reason for the note) you will need to basically shut off the base correction when a player enters an instance and save the difference value to your saved vars, in case the player restarts or logs into an instance instead of the realm world server. This leaves the problem of a user installing the addon and logging on to an instance server first rather than the realm world server (and people who raid know that can really happen a lot, ala "oh let me go enable or install that addon i need, brb"). In this case you will need to seed the base with the difference of the instance server just once and then follow the rule of shutting it off in an instance, where it will naturally be corrected within a minute or so of entering realm world server.

	~~A third choice for consistant times~~ is to ~~mix the two and run a timer correction update event in the background, where you~~ get ~~a base time difference between local and server time as to correct local time to~~ server time, and base seconds (plus diff) purely off of local time. So: seed base -> use local time + base as time value in addon (server time with second precision) -> continue every fraction of second or so to see if server time has rolled over to next minute -> reconcile and update base -> and on and on... ~~The update event basically corrects the base difference over time~~ to ~~keep it acruate with server time~~. ~~The base correction update~~ is ~~necessary because users computers can drift dramatically depending on the computer~~, and ~~because~~ users ~~can choose~~ to ~~change their timezone or clock at any time. Also doing time diffs and adds is not as simple as it sounds;~~ its ~~a bit contrived to get~~ it ~~right~~. What you end up with however is as near second accruacy universal server time across all clients. This depends on how accurate minute rollovers form server time are and using the cients seconds counter should not drift any perceptable amount inside a mintute. I'~~m guessing the wow client itself is basing the server time minute rollovers on local client time as well~~, ~~just~~ not ~~shared with us through this function, and i dont know how often or what triggers actual server~~ time ~~updates to the client. But~~ in ~~practice ive observed this working very very well. However... with the newer problem (the original reason for the note) you will need to basically shut off the base correction when~~ a ~~player enters an instance and save~~ the ~~difference value~~ to ~~your saved vars~~, ~~in case~~ the ~~player restarts or logs into an instance instead~~ of the ~~realm world server. This leaves the problem of~~ a ~~user installing the addon~~ and ~~loging on to an instance server first rather than~~ the ~~realm world server (and people who raid know that can really happen a lot, ala "oh let me go enable or install that addon i need, brb")~~. In this ~~case you will need~~ to ~~seed~~ the ~~base with the difference of the instance~~ server ~~just once~~ and ~~then follow~~ the ~~rule of shutting it off~~ in ~~an instance~~, ~~where it will natuarally be corrected within~~ a ~~minute or so of entering realm world server~~.		This is alot of trouble to get simple consistent server time, adn ... may seem crazy to worry about. For some apps is more than nice to have, ala player joins and leaves for say raid tracker for example and dealing wiht non-trivial things for users to fix after the fact like wtf dkp upload results, its worth it. The core issue isn't having accuracy like an atomic clock, but not having time values jump in a way that makes the data absurd or inconsistent or impossible to process like DKP uploads, and a close second is all users having the basic same time of the day in a consistent format and time zone, which is really the same thing for multi user uploads in my example. All Blizz could do to fix this would be to make a hole where to continue to get server time from the realm server for AddOns and possibly share the seconds counter as a third return value in this API function if there is such a thing, and is all probably not a trivial thing to change.

	This is alot of trouble to get simple consistant server time, adn ... may seem crazy to worry about. For some apps is more than nice to have, ala player joins and leaves for say raid tracker for example and dealing wiht non-trival things for users to fix after the fact like wtf dkp upload results, its worth it. The core issue isnt having accruacy like an atomic clock, but not haivng time values jump in a way that makes the data absurd or inconsistant or impossible to process like dkp uploads, and a close second is all users having the basic same time of the day in a consistant format and time zone, which is really the same thing for multi user uploads in my example. All blizz cound do to fix this would be to make a hole where to continue to get server time from the realm server for addons and possibly share the seconds counter as a third return value in this API function if ther is such a thing, and is all probably not a trivial thing to change.		And.. the server time updates are likely one of two things. They are taken directly from other data for other purposes like timings from one of the standard server game clocks out of packets intended for avatar updates and the like with the seconds clipped off. Or its an out of band update to the clients every so often where there would be no real seconds value to begin with. A third possibility would be what I originally suspected, is that is a very occasional update from the server out of band, and updated by the client based on local time anyway. If is out of band and special the last example would be the least bandwidth by far.

	And.. ~~while im on such a roll.. I suspect~~ the server time updates are one of two things. They are taken directly from other data for other purposes like timings from one of the standard server game clocks out of packets intended for avatar updates and the like with the seconds clipped off. Or its an out of band update to the clients every so often where there would be no real seconds value to begin with. A third ~~possiblity~~ would be what I originally suspected, is that is a very occasional update from the server out of band, and updated by the client based on local time anyway. If is out of band and special the last example would be the least bandwidth by far. ~~Dun make me re-synthesize what would need extra return value pls pls. :)~~

64.132.225.203 at 17:28, 11 July 2017

2017-07-11T17:28:04Z

← Older revision		Revision as of 17:28, 11 July 2017
Line 25:		Line 25:
	So for example you log into US Ysera EST at 18:00, and enter Ulduar runing on an instance server that is PST. Suddenly the time returned will be 3 hours behind the time you were getting. Confusing but important :) Please keep this in mind if using this time for anything important functionally, such as diffing times or using as part of functional historical data.		So for example you log into US Ysera EST at 18:00, and enter Ulduar runing on an instance server that is PST. Suddenly the time returned will be 3 hours behind the time you were getting. Confusing but important :) Please keep this in mind if using this time for anything important functionally, such as diffing times or using as part of functional historical data.

	For getting consistant times you have two basic choices use server or use local client time. Server time is good because all players in a realm will have the same time within more or less a mintue accuracy. Client time is good because you have second precision, but everyones times are different, as not only do people log into realm servers from other timezones, but you also have no idea how correct their local time is, from unset clocks to bad user timezone, and lots of variance. The "instance server not same time as login server" problem suddenly makes the server time much less valuable for consistancy. Two reasons: even if the server is in the same timezone as the login server, you might have variance between the two server like 5-10 mintues, though not typicaly the case. Using local time for most apps where a univeral time isnt important is the way to go.		For getting consistant times you have two basic choices use server or use local client time. Server time is good because all players in a realm will have the same time within more or less a mintue accuracy (difference between two clients can exceed a minute [disregarding hours]). Client time is good because you have second precision, but everyones times are different, as not only do people log into realm servers from other timezones, but you also have no idea how correct their local time is, from unset clocks to bad user timezone, and lots of variance. The "instance server not same time as login server" problem suddenly makes the server time much less valuable for consistancy. Two reasons: even if the server is in the same timezone as the login server, you might have variance between the two server like 5-10 mintues, though not typicaly the case. Using local time for most apps where a univeral time isnt important is the way to go.

	A third choice for consistant times is to mix the two and run a timer correction update event in the background, where you get a base time difference between local and server time as to correct local time to server time, and base seconds (plus diff) purely off of local time. So: seed base -> use local time + base as time value in addon (server time with second precision) -> continue every fraction of second or so to see if server time has rolled over to next minute -> reconcile and update base -> and on and on... The update event basically corrects the base difference over time to keep it acruate with server time. The base correction update is necessary because users computers can drift dramatically depending on the computer, and because users can choose to change their timezone or clock at any time. Also doing time diffs and adds is not as simple as it sounds; its a bit contrived to get it right. What you end up with however is as near second accruacy universal server time across all clients. This depends on how accurate minute rollovers form server time are and using the cients seconds counter should not drift any perceptable amount inside a mintute. I'm guessing the wow client itself is basing the server time minute rollovers on local client time as well, just not shared with us through this function, and i dont know how often or what triggers actual server time updates to the client. But in practice ive observed this working very very well. However... with the newer problem (the original reason for the note) you will need to basically shut off the base correction when a player enters an instance and save the difference value to your saved vars, in case the player restarts or logs into an instance instead of the realm world server. This leaves the problem of a user installing the addon and loging on to an instance server first rather than the realm world server (and people who raid know that can really happen a lot, ala "oh let me go enable or install that addon i need, brb"). In this case you will need to seed the base with the difference of the instance server just once and then follow the rule of shutting it off in an instance, where it will natuarally be corrected within a minute or so of entering realm world server.		A third choice for consistant times is to mix the two and run a timer correction update event in the background, where you get a base time difference between local and server time as to correct local time to server time, and base seconds (plus diff) purely off of local time. So: seed base -> use local time + base as time value in addon (server time with second precision) -> continue every fraction of second or so to see if server time has rolled over to next minute -> reconcile and update base -> and on and on... The update event basically corrects the base difference over time to keep it acruate with server time. The base correction update is necessary because users computers can drift dramatically depending on the computer, and because users can choose to change their timezone or clock at any time. Also doing time diffs and adds is not as simple as it sounds; its a bit contrived to get it right. What you end up with however is as near second accruacy universal server time across all clients. This depends on how accurate minute rollovers form server time are and using the cients seconds counter should not drift any perceptable amount inside a mintute. I'm guessing the wow client itself is basing the server time minute rollovers on local client time as well, just not shared with us through this function, and i dont know how often or what triggers actual server time updates to the client. But in practice ive observed this working very very well. However... with the newer problem (the original reason for the note) you will need to basically shut off the base correction when a player enters an instance and save the difference value to your saved vars, in case the player restarts or logs into an instance instead of the realm world server. This leaves the problem of a user installing the addon and loging on to an instance server first rather than the realm world server (and people who raid know that can really happen a lot, ala "oh let me go enable or install that addon i need, brb"). In this case you will need to seed the base with the difference of the instance server just once and then follow the rule of shutting it off in an instance, where it will natuarally be corrected within a minute or so of entering realm world server.

WoWWiki>Chewish at 10:09, 12 March 2010

2010-03-12T10:09:17Z

← Older revision		Revision as of 10:09, 12 March 2010
Line 25:		Line 25:
	So for example you log into US Ysera EST at 18:00, and enter Ulduar runing on an instance server that is PST. Suddenly the time returned will be 3 hours behind the time you were getting. Confusing but important :) Please keep this in mind if using this time for anything important functionally, such as diffing times or using as part of functional historical data.		So for example you log into US Ysera EST at 18:00, and enter Ulduar runing on an instance server that is PST. Suddenly the time returned will be 3 hours behind the time you were getting. Confusing but important :) Please keep this in mind if using this time for anything important functionally, such as diffing times or using as part of functional historical data.

	For getting consistant times you have two basic choices use server or use local client time. Server time is good because all players in a realm will have the same time within more or less a mintue accuracy. Client time is good because you have second precision, but everyones times are different, as not only do people log into realm servers from other timezones, but you also have no idea how correct their local time is, from unset clocks to bad user ~~tiemzone~~, and lots of variance. The "instance server not same time as login server" problem suddenly makes the server time much less valuable for consistancy. Two reasons: even if the server is in the same timezone as the login server, you might have variance between the two server like 5-10 mintues, though not typicaly the case. Using local time for most apps where a univeral time isnt important is the way to go.		For getting consistant times you have two basic choices use server or use local client time. Server time is good because all players in a realm will have the same time within more or less a mintue accuracy. Client time is good because you have second precision, but everyones times are different, as not only do people log into realm servers from other timezones, but you also have no idea how correct their local time is, from unset clocks to bad user timezone, and lots of variance. The "instance server not same time as login server" problem suddenly makes the server time much less valuable for consistancy. Two reasons: even if the server is in the same timezone as the login server, you might have variance between the two server like 5-10 mintues, though not typicaly the case. Using local time for most apps where a univeral time isnt important is the way to go.

	A third choice for consistant times is to mix the two and run a timer correction update event in the background, where you get a base time difference between local and server time as to correct local time to server time, and base seconds (plus diff) purely off of local time. So: seed base -> use local time + base as time value in addon (server time with second precision) -> continue every fraction of second or so to see if server time has rolled over to next minute -> reconcile and update base -> and on and on... The update event basically corrects the base difference over time to keep it acruate with server time. The base correction update is necessary because users computers can drift dramatically depending on the computer, and because users can choose to change their timezone or clock at any time. Also doing time diffs and adds is not as simple as it sounds; its a bit contrived to get it right. What you end up with however is as near second accruacy universal server time across all clients. This depends on how accurate minute rollovers form server time are and using the cients seconds counter should not drift any perceptable amount inside a mintute. I'm guessing the wow client itself is basing the server time minute rollovers on local client time as well, just not shared with us through this function, and i dont know how often or what triggers actual server time updates to the client. But in practice ive observed this working very very well. However... with the newer problem (the original reason for the note) you will need to basically shut off the base correction when a player enters an instance and save the difference value to your saved vars, in case the player restarts or logs into an instance instead of the realm world server. This leaves the problem of a user installing the addon and loging on to an instance server first rather than the realm world server (and people who raid know that can really happen a lot, ala "oh let me go enable or install that addon i need, brb"). In this case you will need to seed the base with the difference of the instance server just once and then follow the rule of shutting it off in an instance, where it will natuarally be corrected within a minute or so of entering realm world server.		A third choice for consistant times is to mix the two and run a timer correction update event in the background, where you get a base time difference between local and server time as to correct local time to server time, and base seconds (plus diff) purely off of local time. So: seed base -> use local time + base as time value in addon (server time with second precision) -> continue every fraction of second or so to see if server time has rolled over to next minute -> reconcile and update base -> and on and on... The update event basically corrects the base difference over time to keep it acruate with server time. The base correction update is necessary because users computers can drift dramatically depending on the computer, and because users can choose to change their timezone or clock at any time. Also doing time diffs and adds is not as simple as it sounds; its a bit contrived to get it right. What you end up with however is as near second accruacy universal server time across all clients. This depends on how accurate minute rollovers form server time are and using the cients seconds counter should not drift any perceptable amount inside a mintute. I'm guessing the wow client itself is basing the server time minute rollovers on local client time as well, just not shared with us through this function, and i dont know how often or what triggers actual server time updates to the client. But in practice ive observed this working very very well. However... with the newer problem (the original reason for the note) you will need to basically shut off the base correction when a player enters an instance and save the difference value to your saved vars, in case the player restarts or logs into an instance instead of the realm world server. This leaves the problem of a user installing the addon and loging on to an instance server first rather than the realm world server (and people who raid know that can really happen a lot, ala "oh let me go enable or install that addon i need, brb"). In this case you will need to seed the base with the difference of the instance server just once and then follow the rule of shutting it off in an instance, where it will natuarally be corrected within a minute or so of entering realm world server.

Bear at 15:19, 9 December 2009

2009-12-09T15:19:47Z

← Older revision		Revision as of 15:19, 9 December 2009
Line 10:		Line 10:
	local hour,minute = GetGameTime();		local hour,minute = GetGameTime();
	message(hour .. ":" .. minute);		message(hour .. ":" .. minute);

	===Result===		===Result===
	A message with the current server time appears.		A message with the current server time appears.

			==Notes==
			This function can unexpectedly return results inconsistant with actual realm sever time. The value returned is from the physical instance server you are actually playing on, and not that of the world instance server (realm server) you log into. Servers for instances such as for raids and pvp are often shared between login world servers. And instance servers are not always running using the same timezone as the login realm server. This is particualry noticable for Oceanic and other low population world servers. See below for more...

	To use this in a macro:		To use this in a macro:
			/script local hour,minute = GetGameTime(); DEFAULT_CHAT_FRAME:AddMessage(hour .. ":" .. minute);


			==More notes==

			So for example you log into US Ysera EST at 18:00, and enter Ulduar runing on an instance server that is PST. Suddenly the time returned will be 3 hours behind the time you were getting. Confusing but important :) Please keep this in mind if using this time for anything important functionally, such as diffing times or using as part of functional historical data.

			For getting consistant times you have two basic choices use server or use local client time. Server time is good because all players in a realm will have the same time within more or less a mintue accuracy. Client time is good because you have second precision, but everyones times are different, as not only do people log into realm servers from other timezones, but you also have no idea how correct their local time is, from unset clocks to bad user tiemzone, and lots of variance. The "instance server not same time as login server" problem suddenly makes the server time much less valuable for consistancy. Two reasons: even if the server is in the same timezone as the login server, you might have variance between the two server like 5-10 mintues, though not typicaly the case. Using local time for most apps where a univeral time isnt important is the way to go.

			A third choice for consistant times is to mix the two and run a timer correction update event in the background, where you get a base time difference between local and server time as to correct local time to server time, and base seconds (plus diff) purely off of local time. So: seed base -> use local time + base as time value in addon (server time with second precision) -> continue every fraction of second or so to see if server time has rolled over to next minute -> reconcile and update base -> and on and on... The update event basically corrects the base difference over time to keep it acruate with server time. The base correction update is necessary because users computers can drift dramatically depending on the computer, and because users can choose to change their timezone or clock at any time. Also doing time diffs and adds is not as simple as it sounds; its a bit contrived to get it right. What you end up with however is as near second accruacy universal server time across all clients. This depends on how accurate minute rollovers form server time are and using the cients seconds counter should not drift any perceptable amount inside a mintute. I'm guessing the wow client itself is basing the server time minute rollovers on local client time as well, just not shared with us through this function, and i dont know how often or what triggers actual server time updates to the client. But in practice ive observed this working very very well. However... with the newer problem (the original reason for the note) you will need to basically shut off the base correction when a player enters an instance and save the difference value to your saved vars, in case the player restarts or logs into an instance instead of the realm world server. This leaves the problem of a user installing the addon and loging on to an instance server first rather than the realm world server (and people who raid know that can really happen a lot, ala "oh let me go enable or install that addon i need, brb"). In this case you will need to seed the base with the difference of the instance server just once and then follow the rule of shutting it off in an instance, where it will natuarally be corrected within a minute or so of entering realm world server.

			This is alot of trouble to get simple consistant server time, adn ... may seem crazy to worry about. For some apps is more than nice to have, ala player joins and leaves for say raid tracker for example and dealing wiht non-trival things for users to fix after the fact like wtf dkp upload results, its worth it. The core issue isnt having accruacy like an atomic clock, but not haivng time values jump in a way that makes the data absurd or inconsistant or impossible to process like dkp uploads, and a close second is all users having the basic same time of the day in a consistant format and time zone, which is really the same thing for multi user uploads in my example. All blizz cound do to fix this would be to make a hole where to continue to get server time from the realm server for addons and possibly share the seconds counter as a third return value in this API function if ther is such a thing, and is all probably not a trivial thing to change.

	~~/script~~ local ~~hour,minute = GetGameTime();DEFAULT_CHAT_FRAME:AddMessage (hour~~ .. ":~~" .. minute~~);		And.. while im on such a roll.. I suspect the server time updates are one of two things. They are taken directly from other data for other purposes like timings from one of the standard server game clocks out of packets intended for avatar updates and the like with the seconds clipped off. Or its an out of band update to the clients every so often where there would be no real seconds value to begin with. A third possiblity would be what I originally suspected, is that is a very occasional update from the server out of band, and updated by the client based on local time anyway. If is out of band and special the last example would be the least bandwidth by far. Dun make me re-synthesize what would need extra return value pls pls. :)

WoWWiki>Exawatt: /* Returns */ Added value ranges.

2009-05-11T06:03:18Z

Returns: Added value ranges.

← Older revision		Revision as of 06:03, 11 May 2009
Line 4:		Line 4:
	==Parameters==		==Parameters==
	===Returns===		===Returns===
	:;hours : Number - The current hour.		:;hours : Number - The current hour (0-23).
	:;minutes : Number - The minutes passed in the current hour.		:;minutes : Number - The minutes passed in the current hour (0-59).

	==Example==		==Example==

WoWWiki>Ludinom: /* Example */

2007-10-06T17:01:05Z

Example

← Older revision		Revision as of 17:01, 6 October 2007
Line 12:		Line 12:
	===Result===		===Result===
	A message with the current server time appears.		A message with the current server time appears.

			To use this in a macro:

			/script local hour,minute = GetGameTime();DEFAULT_CHAT_FRAME:AddMessage (hour .. ":" .. minute);

WoWWiki>Starlightblunder: {{wowapi}}, format

2006-12-24T00:32:08Z

{{wowapi}}, format

← Older revision		Revision as of 00:32, 24 December 2006
Line 1:		Line 1:
	~~<center>'''GetGameTime''' ''-Documentation by [[user:Zlixar\|Zlixar]]-''</center>~~		{{wowapi}} __NOTOC__

	Returns the current server time in hours and minutes		Returns the current server time in hours and minutes
	hours,minutes = GetGameTime();		hours,minutes = GetGameTime();
	~~----~~		==Parameters==
	~~;''Arguments''~~		===Returns===

	~~:''none''~~

	~~----~~
	~~;''~~Returns''

	:;hours : Number - The current hour.		:;hours : Number - The current hour.
	:;minutes : Number - The minutes passed in the current hour.		:;minutes : Number - The minutes passed in the current hour.

	~~----~~		==Example==
	~~;''~~Example''

	local hour,minute = GetGameTime();		local hour,minute = GetGameTime();
	~~;''Result''~~		message(hour .. ":" .. minute);
	hour ~~= 16~~		===Result===
	minute ~~= 30~~		A message with the current server time appears.

	~~----~~
	;~~''Details''~~

	~~:This is~~ the server~~'s current time, NOT the current~~ time ~~of the user's system~~.

	~~----~~
	~~{{WoW API}}~~

WoWWiki>Muert at 05:00, 4 January 2006

2006-01-04T05:00:21Z

← Older revision		Revision as of 05:00, 4 January 2006
Line 26:		Line 26:

	:This is the server's current time, NOT the current time of the user's system.		:This is the server's current time, NOT the current time of the user's system.

	----		----
	{{~~Template:~~WoW API}}		{{WoW API}}
	~~[[Category:API Functions\|GetGameTime]]~~
	~~[[Category:API Core Functions\|GetGameTime]]~~