This is a new library that allows you to subscribe to in-game time, date, and moon phase updates, or get the current time, date, or moon phase directly. You can also retrieve the data for a specific date.
The library is a product of my recent efforts to update my addon Clock - Tamriel Standard Time. I had to completely rewrite it, it hasn't aged very well, and separated the logic from the UI. This is the logical part.
Feel free to create your own user interface based on this library without worrying about the mathematics of calculating time, date and moon phase. Or download the new UI part of Clock - Tamriel Standard Time.
If you like, you can try it out and leave me a feedback in the comments or at GitHub. Especially, if you found a bug.
Version 1.0.2: (Phinix)
- Updated for Scribes of Fate.
Version 1.0.1: (Phinix)
- Modified LibClockTST.GetWeekDay function to derive day-of-week value using unix epoch timestamps as the previous method was off by 1 for December 2021 and probably other dates.
- Updated API version for Deadlands.
- EDIT: Update without version change (12-11-21) to fix logic error/typo.
- EDIT: Update without version change for Ascending Tide.
Version 1.0.0:
- Initial release.
- API bump for Waking Flame update without version change (Phinix)
- Changed addon Minor version to 1 and changed ## AddOnVersion to 1 in the manifest to match. (Thanks for the heads-up Baertram!)
is essential if you use ## IsLibrary: true to let the ingame addon manager determine the "newest" version of the addon/library.
You shouldn't use a number 0 here but same/similar to the non-official ## Version tag! ## Version is currently ONLY used within Minion, the external addon manager. It's not used ingame by ESO. Therefor ## AddOnVersion is to be used.
I'm not sure if the ingame addon manager will detect 0 as a valid version, and if you got a version > 0 the same time would count as newer then.
I hope so
is essential if you use ## IsLibrary: true to let the ingame addon manager determine the "newest" version of the addon/library.
You shouldn't use a number 0 here but same/similar to the non-official ## Version tag! ## Version is currently ONLY used within Minion, the external addon manager. It's not used ingame by ESO.
Updated without version change. Made the above correction beginning version incrementation at 1 (should probably also be noted that ## AddOnVersion must be a whole number, so no decimal values), and updated the library Minor version to match.
Thanks for the heads-up! To be honest, I have been using this library with ClockTST with "allow out of date" and encountered no problems. The changes I made to the main addon since coming onboard have been essentially cosmetic, so I hadn't really needed to dig into this part, other than to confirm everything appears to be working as far as time constants syncing up to the lunar cycle observable in-game.
So, it will work with the addon version at 0, if you check allow outdated, which I heard might be going away(?). However, there may be an issue where it will still show out of date even if ##APIVersion is current, but I haven't tested it.
I am preparing to use LibClockTST in The Elder Bar Reloaded, and I noticed something glaringly missing from this otherwise great library: a function to convert month number to name (preferably both Imperial and Argonian). Of course, I have implemented it myself, but it would be nice if LibClockTST provided it. Even better, if :GetTime() and :GetDate methods optionally took two arguments, like os.date does:
Unfortunately, the following UI Error was displayed on the HUD after my character was loaded to play:
Code:
user:/AddOns/ClockTST/Lib/Feature/Time/Time.lua:312: attempt to index a nil value
stack traceback:
user:/AddOns/ClockTST/Lib/Feature/Time/Time.lua:312: in function 'Time:CreateDateReplacements'
|caaaaaa<Locals> self = [table:1]{sizeHasUpdated = T}, loreDate = [table:2]{year = 614, weekDay = 5, era = 2, day = 20, month = 1}, realDateString = 20211219, ry = 2021, rm = 12, rd = 19, rw = 0 </Locals>|r
user:/AddOns/ClockTST/Lib/Feature/Time/Time.lua:365: in function 'Time:UpdateTime'
|caaaaaa<Locals> self = [table:1], time = [table:3]{hour = 0, minute = 23, second = 28}, date = [table:2] </Locals>|r
user:/AddOns/ClockTST/Lib/Feature/Time/Time.lua:392: in function 'f'
|caaaaaa<Locals> time = [table:3], date = [table:2] </Locals>|r
user:/AddOns/LibClockTST/Lib/LibClockTST.lua:497: in function 'OnUpdate'
|caaaaaa<Locals> _ = "ClockTST", f =
user:/AddOns/ClockTST/Lib/Feature/Time/Time.lua:391 </Locals>|r
From what I could see of it behind the UI Error display window, the Clock 2.0 output on the HUD is missing at least one line, whether it is the first or the second.
Isn't defining LibClockTST = {} as a table and using LibClockTST:New OO approach returning the same table LibClockTST again a bit of a problem?
LibClockTST will be the class providing the constants itsself and returning every time the same clock table, instead of a new created "proper object" of ZO_Object:Subclass, if you use :New.
Why using a OO approach then instead of simple 1 table LibClockTST and always returning that? Just for the "sake of : notation and : new usage?" it would not make sense imo.
But I have not checked the code of the addons that use this library so there maybe a point for it. Currently I only see confusion here, at least for me
As creating multiple clocks from that lib will always return the very same object, right?
@Baertram - I have barely done anything with LibClockTST. I just keep it updated for the main addon which is what I have mainly worked on in the past. I have never had reason to go re-writing the original author's library since "it just works" and no one ever reported any issues, however I will look into the situation you mention.
Hey Phinix, I did not see you took it over (thought it was Tyx) sorry. Just saw the update and wondered about the object/class structure.
Originally Posted by Phinix
@Baertram - I have barely done anything with LibClockTST. I just keep it updated for the main addon which is what I have mainly worked on in the past. I have never had reason to go re-writing the original author's library since "it just works" and no one ever reported any issues, however I will look into the situation you mention.
To make a mod, even a small one, is hard work and consumes a lot of time,
but I don't do it for any reason than the fun of programming and seeing a product work as planned.
Still, to get a donation, even a small one, boosts my motivation to continue developing this addon immense
You can also contribute by leaving a feedback at the comments or at GitHub
(critic if constructive is welcome as well)
You have just downloaded by the author . If you like this AddOn why not consider supporting the author? This author has set up a donation account. Donations ensure that authors can continue to develop useful tools for everyone.
*Clicking the donate button above will take you to PayPal.com
*Clicking the donate button above will take you to Pledgie.com